Hi and thanks for your reply. Currently the kernel is 4.8.4 stable, gp8psk kernel driver, vdr-2.2.0. However, this problem has been going on for quite a while - I'm just now getting around to asking about it. The drivers I use haven't been changed in years so I'm not sure that's where the root cause is. It's interesting that you've experienced it as well with a completely different card/drivers. I wonder if downgrading your drivers really had any affect of it the conditions which cause the problem to surface just haven't happened yet. Hopefully others will chime in as well and we can get to the bottom of it. It may be an infrequent problem but it has a nasty result!

-Derek

On 26.11.2017 19:09, Teemu Suikki wrote:

I know I'm replying to a year old thread, but I'm having the exact same problem.

I upgraded my system from kernel 3.16.0 to 4.4.0, and also TBS dvb drivers to latest version.. Now I have this problem, that randomly VDR starts flooding this "ERROR: TS packet not accepted in Transfer Mode" log. It will not jam right away, but after maybe 30-60min it is jammed.

Some VDR functions like timers seem to still work, but the GUI is stuck.

This is VDR 2.2.0 from yavdr repos.

Any ideas?

Even though this might be a driver bug, perhaps vdr of softhddevice could simply stop displaying the channel after the first error?

I can't contribute anything regarding the driver or softhddevice, but I guess limiting the log message to, say, one message per minute could save the program from getting stuck. That's assuming your log is actually flooded with thousands of entries like that. To qickly verify this could you please precede the line

esyslog("ERROR: TS packet not accepted in Transfer Mode");

in transfer.c with

static int Counter = 0; if ((Counter++ % 10000) == 0)

Klaus

On 27.11.2017 09:04, Teemu Suikki wrote:

I made this change few hours ago, but I'm still waiting for the problem to appear.. Obviously it now is working 100%. :)

Does "working 100%" mean that youre not getting any of these error messages any more? Not even once?

Klaus

2017-11-27 0:08 GMT+02:00 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:

...

On 26.11.2017 19:09, Teemu Suikki wrote:

...

I know I'm replying to a year old thread, but I'm having the exact same problem.

I upgraded my system from kernel 3.16.0 to 4.4.0, and also TBS dvb drivers to latest version.. Now I have this problem, that randomly VDR starts flooding this "ERROR: TS packet not accepted in Transfer Mode" log. It will not jam right away, but after maybe 30-60min it is jammed.

Some VDR functions like timers seem to still work, but the GUI is stuck.

This is VDR 2.2.0 from yavdr repos.

Any ideas?

Even though this might be a driver bug, perhaps vdr of softhddevice could simply stop displaying the channel after the first error?

I can't contribute anything regarding the driver or softhddevice, but I guess limiting the log message to, say, one message per minute could save the program from getting stuck. That's assuming your log is actually flooded with thousands of entries like that. To qickly verify this could you please precede the line

esyslog("ERROR: TS packet not accepted in Transfer Mode");

in transfer.c with

static int Counter = 0; if ((Counter++ % 10000) == 0)

Klaus

...

I made this change few hours ago, but I'm still waiting for the problem to appear.. Obviously it now is working 100%. :)

Same here.

Does "working 100%" mean that youre not getting any of these error messages any more? Not even once?

I'm not getting them right now either but it only means the conditions that cause it haven't occurred yet. It will though - it always does sooner or later unfortunately.

It still does lock up.

I think it is really softhddevice problem, as the lockup only happens if actually viewing the channel.. My VDR box is always on, and usually I just turn off the projector and leave VDR running. Perhaps I need to change my habits and actually suspend softhddevice when not really watching it.

Some log, not really useful though. It starts with the "TS packet not accepted", which now only appears once because of the modification Klaus suggested. But there's still a lot of other output that is probably the cause of the lockup.

One thing that came to mind. In my previous setup with much older kernel and DVB drivers, sometimes VDR/softhddevice lost audio completely when left running for a long time. Video was running but no audio. Audio only came back after suspend/resume of softhddevice, channel switch didn't wake it up. Perhaps this is the same bug, but now it keeps going trying to restart audio?

Dec 8 20:22:56 puucee vdr: [20880] [softhddev]Clear: Dec 8 20:22:56 puucee vdr: [20880] ERROR: TS packet not accepted in Transfer Mode Dec 8 20:22:56 puucee vdr: audio/alsa: using device 'default' Dec 8 20:22:56 puucee vdr: [20880] [softhddev]Clear: Dec 8 20:22:56 puucee vdr: audio/alsa: start delay 1000ms Dec 8 20:22:56 puucee vdr: [20880] [softhddev]Clear: Dec 8 20:22:56 puucee vdr: audio/alsa: using device 'default' Dec 8 20:22:56 puucee vdr: [20880] [softhddev]Clear: Dec 8 20:22:56 puucee vdr: audio/alsa: start delay 1000ms Dec 8 20:22:56 puucee vdr: audio/alsa: using device 'default'

That is continued for hundreds of lines, then this:

Dec 8 20:22:59 puucee vdr: [20880] [softhddev]Clear: Dec 8 20:22:59 puucee vdr: audio/alsa: start delay 1000ms Dec 8 20:22:59 puucee vdr: [20881] buffer usage: 70% (tid=20880) Dec 8 20:22:59 puucee vdr: [20880] [softhddev]Clear:

later 80%, 90%, 100%

After that new kind of errors:

Dec 8 20:23:01 puucee vdr: [20880] ERROR: skipped 60 bytes to sync on start of TS packet Dec 8 20:23:01 puucee vdr: audio/alsa: start delay 1000ms Dec 8 20:23:01 puucee vdr: [20880] ERROR: skipped 64 bytes to sync on start of TS packet Dec 8 20:23:01 puucee vdr: [20880] [softhddev]Clear: Dec 8 20:23:01 puucee vdr: [20880] ERROR: skipped 64 bytes to sync on start of TS packet Dec 8 20:23:01 puucee vdr: audio/alsa: using device 'default' Dec 8 20:23:01 puucee vdr: [20880] [softhddev]Clear: Dec 8 20:23:01 puucee vdr: audio/alsa: start delay 1000ms

<snip>

Dec 8 20:23:03 puucee vdr: [20881] ERROR: driver buffer overflow on device 4 Dec 8 20:23:03 puucee vdr: [20880] [softhddev]Clear: Dec 8 20:23:03 puucee vdr: audio/alsa: start delay 1000ms

<snip>

Dec 8 20:28:02 puucee vdr: [20880] ERROR: skipped 13 bytes to sync on start of TS packet Dec 8 20:28:02 puucee vdr: [20880] [softhddev]Clear: Dec 8 20:28:02 puucee vdr: audio: can't set channels 2 sample-rate 0Hz Dec 8 20:28:02 puucee vdr: [20880] ERROR: skipped 179 bytes to sync on start of TS packet

That 0Hz error is now also repeated for the rest of the log..

at 20:35 I restarted vdr:

Dec 8 20:35:42 puucee vdr: [20880] ERROR: skipped 92 bytes to sync on start of TS packet Dec 8 20:35:42 puucee vdr: [20880] [softhddev]Clear: Dec 8 20:35:42 puucee vdr: audio: can't set channels 2 sample-rate 0Hz Dec 8 20:35:42 puucee vdr: [20880] ERROR: skipped 188 bytes to sync on start of TS packet Dec 8 20:35:42 puucee vdr: [20880] ERROR: skipped 188 bytes to sync on start of TS packet Dec 8 20:35:42 puucee systemd[1]: vdr.service: State 'stop-sigterm' timed out. Killing. Dec 8 20:35:42 puucee systemd[1]: vdr.service: Main process exited, code=killed, status=9/KILL Dec 8 20:35:42 puucee systemd[1]: Stopped Video Disk Recorder.

Before restart, I used the "femon" command on shell, and all my tuners showed good signal with no errors and locked state... So, even if the problem might be started by some error in the stream, it surely should correct itself? Maybe try retuning with different tuner instead of throwing 3000 lines of errors to log? :)

2017-11-27 20:04 GMT+02:00 Teemu Suikki tsuikki@zuik.org:

I now switched to the open source TBS drivers. They seem more stable than the official proprietary drivers.. So hopefully this problem is gone too.

But sadly Klaus' change is now untested, TS error did not occur even once today with old drivers. We'll see what happens with new ones. :)

2017-11-27 17:24 GMT+02:00 VDR User user.vdr@gmail.com:

...

...

...

I made this change few hours ago, but I'm still waiting for the problem to appear.. Obviously it now is working 100%. :)

Same here.

...

Does "working 100%" mean that youre not getting any of these error messages any more? Not even once?

I'm not getting them right now either but it only means the conditions that cause it haven't occurred yet. It will though - it always does sooner or later unfortunately.

---

vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

-- Teemu Suikki http://www.z-power.fi/

Any ideas how to get this fixed? This is really getting on my nerves now.

I now detach softhddevice always when I stop watching. It does not freeze then. But sometimes it freezes right after I attach it! Just a few seconds of working video and BANG frozen. Really annoying!

Another thing which might be related. On my earlier setup, if I paused playback, softhddevice would mute the sound. On this setup, audio is not muted, it is looping the last buffer until playback continues. That also is an annoying feature. :)

I'm pretty sure I have exact same versions of all VDR software and plugins, only things changed are the Linux kernel, TBS media drivers, and possibly the nvidia vdpau drivers.. Everything worked just fine earlier!

2017-12-09 3:05 GMT+02:00 VDR User user.vdr@gmail.com:

...

It still does lock up.

I think it is really softhddevice problem, as the lockup only happens if actually viewing the channel.. My VDR box is always on, and usually I just turn off the projector and leave VDR running. Perhaps I need to change my habits and actually suspend softhddevice when not really watching it.

Ideally you should be able to run VDR 24/7 without issue. That's what I do and have no intention of changing the habit. Unfortunately softhddevice is no longer actively developed by its' author but there are still some coders in the VDR community who have helped keep it updated. It's possible they may be able to help fix this bug if enough information can be provided. In my cause the frozen/defunct VDR seems to occur if I lose signal for some unknown length of time, and doesn't seem related to audio. Fortunately it's the only problem I have and it doesn't happen daily. It would however be great if it were fixed - hopefully we'll get to that point.

---

vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr