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@xxxxxxxx>: > 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@xxxxxxxxx>: >>>> 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@xxxxxxxxxxx >> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > > > -- > Teemu Suikki > http://www.z-power.fi/ -- Teemu Suikki http://www.z-power.fi/ 2017-11-27 20:04 GMT+02:00 Teemu Suikki <tsuikki@xxxxxxxx>: > 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@xxxxxxxxx>: >>>> 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@xxxxxxxxxxx >> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > > > -- > Teemu Suikki > http://www.z-power.fi/ -- Teemu Suikki http://www.z-power.fi/ _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
