Re: [vdr] VDR locking up

[Teemu Suikki]

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 :
>> 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



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

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

Re: [vdr] VDR locking up

[Teemu Suikki]

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



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



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 :
> 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 :
 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
>> 

Re: [vdr] VDR locking up

[VDR User]

>> 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

Re: [vdr] VDR locking up

[Teemu Suikki]

yes, that's exactly what it means. :) Just bad (or good!) luck.
Yesterday it got stuck three times during the day.

The weather is better today. I think the error is caused by weak signal..


2017-11-27 12:04 GMT+02:00 Klaus Schmidinger :
> 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 :
>>>
>>> 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++ % 1) == 0)
>>>
>>> Klaus
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



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

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

Re: [vdr] VDR locking up

[Klaus Schmidinger]

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 :

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++ % 1) == 0)

Klaus


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

Re: [vdr] VDR locking up

[Teemu Suikki]

Thanks!

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

I now also got the open source TBS drivers to build properly, if they
work nicely I might switch over. Perhaps it fixes this too.


2017-11-27 0:08 GMT+02:00 Klaus Schmidinger :
> 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++ % 1) == 0)
>
> Klaus
>
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



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

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

Re: [vdr] VDR locking up

[Klaus Schmidinger]

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++ % 1) == 0)

Klaus


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

Re: [vdr] VDR locking up

[Teemu Suikki]

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?


2016-10-29 19:32 GMT+03:00 VDR User :
> 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
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



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

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

Re: [vdr] VDR locking up

[VDR User]

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

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

Re: [vdr] VDR locking up

[Ingo Prochaska]

Hi there,


it would be good to know which kernel, driver, card and vdr you are 
using. I´ve seen exactly this logging (including freezing) just 
yesterday: I've updated my kernel from vanilla 4.4.27 to 28; on that way 
I also updated the dvb drivers for my cine S2 V6 from 
https://github.com/herrnst/dddvb-linux-kernel.git. After that I got 
randomly the "TS Paket not accepted in Transfer Mode." I say randomly, 
because I had no weak or droped signal. After switching back to the 
revision of 10/22 ( bc9b91e) kernel 4.4.28 is running as smooth as 
4.4.27 with this git revision.



Good luck hunting this down, Ingo


Am 28.10.2016 um 22:39 schrieb VDR User:

Occasionally my signal drops out (haven't looked into it yet), and it
causes VDR to completely freeze and become defunct/zombie. That locks
up the drivers and the only way to resolve it is by rebooting. No core
file gets created. Does anyone know how to prevent the lock-up in the
first place? Could it be some kind of leak from the looping (see log
clip below)?

Here's a clip of the log when it happens. You can see how the log gets
filled with the same repeating lines until it crashes.

2016.Oct.28|12:08:55 video: slow down video, duping frame
2016.Oct.28|12:08:55 video: decoder buffer empty, duping frame
(5656/167423) 7 v-buf
2016.Oct.28|12:09:29 video: slow down video, duping frame
2016.Oct.28|12:16:09 [1297] [softhddev]Clear:
2016.Oct.28|12:16:09 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:09 audio/alsa: using device 'default'
2016.Oct.28|12:16:09 audio/alsa: start delay 336ms
2016.Oct.28|12:16:09 [1297] [softhddev]Clear:
2016.Oct.28|12:16:10 audio/alsa: using device 'default'
2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:10 audio/alsa: start delay 336ms
2016.Oct.28|12:16:10 [1297] [softhddev]Clear:
2016.Oct.28|12:16:10 audio/alsa: using device 'default'
2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:10 audio/alsa: start delay 336ms
2016.Oct.28|12:16:10 [1297] [softhddev]Clear:
2016.Oct.28|12:16:10 audio/alsa: using device 'default'
2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:10 audio/alsa: start delay 336ms
2016.Oct.28|12:16:10 [1297] [softhddev]Clear:
2016.Oct.28|12:16:10 audio/alsa: using device 'default'
2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:10 audio/alsa: start delay 336ms
2016.Oct.28|12:16:10 [1297] [softhddev]Clear:
2016.Oct.28|12:16:10 audio/alsa: using device 'default'
2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:10 audio/alsa: start delay 336ms
2016.Oct.28|12:16:10 [1297] [softhddev]Clear:
2016.Oct.28|12:16:10 audio/alsa: using device 'default'
2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:11 audio/alsa: start delay 336ms
2016.Oct.28|12:16:11 [1297] [softhddev]Clear:
2016.Oct.28|12:16:11 audio/alsa: using device 'default'
2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:11 audio/alsa: start delay 336ms
2016.Oct.28|12:16:11 [1297] [softhddev]Clear:
2016.Oct.28|12:16:11 audio/alsa: using device 'default'
2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:11 audio/alsa: start delay 336ms
2016.Oct.28|12:16:11 [1297] [softhddev]Clear:
2016.Oct.28|12:16:11 audio/alsa: using device 'default'
2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:11 audio/alsa: start delay 336ms
2016.Oct.28|12:16:11 [1297] [softhddev]Clear:
2016.Oct.28|12:16:11 audio/alsa: using device 'default'
2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:11 audio/alsa: start delay 336ms
2016.Oct.28|12:16:11 [1297] [softhddev]Clear:
2016.Oct.28|12:16:11 audio/alsa: using device 'default'
2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:11 audio/alsa: start delay 336ms
2016.Oct.28|12:16:11 [1297] [softhddev]Clear:
2016.Oct.28|12:16:12 audio/alsa: using device 'default'
2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:12 audio/alsa: start delay 336ms
2016.Oct.28|12:16:12 [1297] [softhddev]Clear:
2016.Oct.28|12:16:12 audio/alsa: using device 'default'
2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:12 audio/alsa: start delay 336ms
2016.Oct.28|12:16:12 [1297] [softhddev]Clear:
2016.Oct.28|12:16:12 audio/alsa: using device 'default'
2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:12 audio/alsa: start delay 336ms
2016.Oct.28|12:16:12 [1297] [softhddev]Clear:
2016.Oct.28|12:16:12 audio/alsa: using device 'default'
2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:12 audio/alsa: start 

[vdr] VDR locking up

[VDR User]

Occasionally my signal drops out (haven't looked into it yet), and it
causes VDR to completely freeze and become defunct/zombie. That locks
up the drivers and the only way to resolve it is by rebooting. No core
file gets created. Does anyone know how to prevent the lock-up in the
first place? Could it be some kind of leak from the looping (see log
clip below)?

Here's a clip of the log when it happens. You can see how the log gets
filled with the same repeating lines until it crashes.

2016.Oct.28|12:08:55 video: slow down video, duping frame
2016.Oct.28|12:08:55 video: decoder buffer empty, duping frame
(5656/167423) 7 v-buf
2016.Oct.28|12:09:29 video: slow down video, duping frame
2016.Oct.28|12:16:09 [1297] [softhddev]Clear:
2016.Oct.28|12:16:09 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:09 audio/alsa: using device 'default'
2016.Oct.28|12:16:09 audio/alsa: start delay 336ms
2016.Oct.28|12:16:09 [1297] [softhddev]Clear:
2016.Oct.28|12:16:10 audio/alsa: using device 'default'
2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:10 audio/alsa: start delay 336ms
2016.Oct.28|12:16:10 [1297] [softhddev]Clear:
2016.Oct.28|12:16:10 audio/alsa: using device 'default'
2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:10 audio/alsa: start delay 336ms
2016.Oct.28|12:16:10 [1297] [softhddev]Clear:
2016.Oct.28|12:16:10 audio/alsa: using device 'default'
2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:10 audio/alsa: start delay 336ms
2016.Oct.28|12:16:10 [1297] [softhddev]Clear:
2016.Oct.28|12:16:10 audio/alsa: using device 'default'
2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:10 audio/alsa: start delay 336ms
2016.Oct.28|12:16:10 [1297] [softhddev]Clear:
2016.Oct.28|12:16:10 audio/alsa: using device 'default'
2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:10 audio/alsa: start delay 336ms
2016.Oct.28|12:16:10 [1297] [softhddev]Clear:
2016.Oct.28|12:16:10 audio/alsa: using device 'default'
2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:11 audio/alsa: start delay 336ms
2016.Oct.28|12:16:11 [1297] [softhddev]Clear:
2016.Oct.28|12:16:11 audio/alsa: using device 'default'
2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:11 audio/alsa: start delay 336ms
2016.Oct.28|12:16:11 [1297] [softhddev]Clear:
2016.Oct.28|12:16:11 audio/alsa: using device 'default'
2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:11 audio/alsa: start delay 336ms
2016.Oct.28|12:16:11 [1297] [softhddev]Clear:
2016.Oct.28|12:16:11 audio/alsa: using device 'default'
2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:11 audio/alsa: start delay 336ms
2016.Oct.28|12:16:11 [1297] [softhddev]Clear:
2016.Oct.28|12:16:11 audio/alsa: using device 'default'
2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:11 audio/alsa: start delay 336ms
2016.Oct.28|12:16:11 [1297] [softhddev]Clear:
2016.Oct.28|12:16:11 audio/alsa: using device 'default'
2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:11 audio/alsa: start delay 336ms
2016.Oct.28|12:16:11 [1297] [softhddev]Clear:
2016.Oct.28|12:16:12 audio/alsa: using device 'default'
2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:12 audio/alsa: start delay 336ms
2016.Oct.28|12:16:12 [1297] [softhddev]Clear:
2016.Oct.28|12:16:12 audio/alsa: using device 'default'
2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:12 audio/alsa: start delay 336ms
2016.Oct.28|12:16:12 [1297] [softhddev]Clear:
2016.Oct.28|12:16:12 audio/alsa: using device 'default'
2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:12 audio/alsa: start delay 336ms
2016.Oct.28|12:16:12 [1297] [softhddev]Clear:
2016.Oct.28|12:16:12 audio/alsa: using device 'default'
2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:12 audio/alsa: start delay 336ms
2016.Oct.28|12:16:12 [1297] [softhddev]Clear:
2016.Oct.28|12:16:12 audio/alsa: using device 'default'
2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:12 audio/alsa: start delay 336ms
2016.Oct.28|12:16:12 [1297] [softhddev]Clear:
2016.Oct.28|12:16:12 audio/alsa: using device 'default'
2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:13 audio/alsa: start delay 336ms
2016.Oct.28|12:16:13 [1297] [softhddev]Clear:
2016.Oct.28|12:16:13 audio/alsa: using device 'default'
2016.Oct.28|12:16:13 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:13