[mythtv-users] Zero Byte Recordings

[Andrew C. (AFPup) Stadt]

On 14/09/2014 8:59 AM, Andrew Potter wrote:
> Hi All,
>
>   
>
> I have been using Myth TV for about 2 ½ years or so with not many issues at
> all, it is a credit to the devs.
>
>   
>
> Recently in an attempt to reduce power consumption I followed the ACPI
> wakeup/Sleep instructions and have run into an issue with Zero Byte
> Recordings.
>
>   
>
> The backend is set to shutdown. It is most often one or two of the first
> scheduled recordings after a restart that seem to fail.
>
>   
>
> I have three separate PlayTV tuners ( 6 tuners in total) and a HVR-2200 PCI
> tuner board. The three play tv units are added first, then the HVR unit.
> Recording is set to use tuners 1 onwards with Live TV as the last tuner
> backwards.
>
>   
>
> I have tried to get the playtv tuners to turn off when the computer is off
> but have not had any success. The motherboard is a ASUS board and I have
> played with the ERP settings and can now see that the optical mouse does
> turn off but the red light on the playtv tuners stays on. I suppose I am
> guessing the tuners do not always come up correctly.
>
>   
>
> Any pointers as to where I can go next is appreciated. I have listed some
> details below including a backend log.
>
>   
>
> I am running mythbuntu 12.04 64-bit on the backend.
>
>   
>
> Myth Version
>
> MythTV Version : v0.27.3-159-g2d4a7c9
>
> MythTV Branch : fixes/0.27
>
> Network Protocol : 77
>
> Library API : 0.27.20140719-1
>
> QT Version : 4.8.1
>
> Options compiled in:
>
> linux profile use_hidesyms using_alsa using_oss using_pulse
> using_pulseoutput using_backend using_bindings_perl using_bindings_python
> using_bindings_php using_crystalhd using_dvb using_firewire using_frontend
> using_hdhomerun using_ceton using_hdpvr using_ivtv using_joystick_menu
> using_libcec using_libcrypto using_libdns_sd using_libfftw3 using_libxml2
> using_lirc using_mheg using_opengl using_opengl_video using_qtwebkit
> using_qtscript using_qtdbus using_sdl using_taglib using_v4l2 using_x11
> using_xrandr using_xv using_profiletype using_bindings_perl
> using_bindings_python using_bindings_php using_mythtranscode using_opengl
> using_vaapi using_vdpau using_ffmpeg_threads using_mheg using_libass
> using_libxml2
>
>   
>
> I have added the mythbackend log ( a truncated version) to pastebin at
> http://paste.ubuntu.com/8342641/
>
>   
>
> There are zero byte recordings started at
>
> 1:55pm on 12/9
>
> 5:55pm on 12/9
>
> 6:55pm on 12/9
>
> 6:55pm on 12/9
>
>   
>
> Then at 6:56pm on 12/9 the recording is successful.
>
>   
>
> Also see times 10:55am on the 13/9 for a zero byte and 3:25pm on 13/9 for a
> successful recording.
>
>   
>
> Thanks Andrew
>
>
No experience myself with those tuners, but in general you can get some 
weird stuff occurring with usb devices after suspend. As Mike suggested, 
there is a theoretical possibility that the tuners might renumber 
themselves on resume (never had it happen personally, but can't deny the 
possibility)  so you might want to consider udev rules to rename the 
devices to something static.

Probably more to the point, I've always finds it helps to unload 
whichever kernel module(s) are responsible for the devices giving you 
issues during the suspend stage, then reloading them manually during the 
resume. Of course you don't want to do this for all your usb devices if 
you're using a usb device to signal the 'wake', just the ones giving you 
issues.

eg: For one of my frontends (tunerless is this instance), the led 
display (with ir receiver) don't play nicely with suspend, so I have a 
script in /etc/pm/sleep.d/ that stops lirc, LCDd and unloads the usb 
modules during hibernate/suspend cycles and then does the reverse during 
thaw/resume cycles.  Incidentally I have another script which gets 
called to ensure that myth is at the main menu... my nVidia card would 
almost never resume cleanly during a thaw/resume for some reason.

HTH,

Andrew.