[mythtv-users] analog recordings won't play with some devices (long and confusing)

belcampo belcampo at zonnet.nl
Tue May 11 20:03:11 UTC 2010


D. Hugh Redelmeier wrote:
> I have two MythTV backends that record analog signals using Hauppauge
> tuners and am having trouble playing the recordings with various
> non-Myth devices.
> 
> Mysteries:
> 
> - why can mplayer not play some of my recordings from MythTV 0.22
>   while it can play recordings from MythTV 0.20?
> 
> - why can Linux-based XBMC not play my recordings with MythTV 0.22 but
>   it can play recordings from MythTV 0.20?  Yet OSX-based XBMC can
>   play them.
Because the OSX-based version will have additional codecs which the 
precompiled linux-based version lacks. Self compiling XBMC is the solution.
> 
> - why can WDTV not play any of my MythTV recordings (albeit with two
>   different failure modes)?
> 
> 
> Details (very long!):
> 
> Recording systems:
> 
> (1) an old MythTV 0.20 setup (32-bit system Fedora Core 5).
>     Uses a PVR-250 and a few Adaptec VideOH! AVC 2410 cards (a lot
>     like a PVR-150).
>     Recording Profile: width 352, Height 480, CODEC MPEG-2,
>     Stream Type MPEG-2 PS, Aspect Ratio 4:3,
>     (video) Avg bitrate 2251, Max bitrate 3009,
>     (audio) sampling rate 3200, type Layer 2, Bitrate 384Kb/s,
>     SAP/bilingual main language, Volume (%) 90.
> 
> (2) a newer Mythbuntu with MythTV 0.22 (64-bit).
>     Uses the analog sections of two Hauppauge HVR 1600 tuners.
>     The driver for the tuners is from the hg repository since
>     the one in Ubuntu's kernel isn't stable.
> 
>     (a) default recording profile.  Similar to (1) except
>         width 480, Avg bitrate 4500, Max bitrate 6000,
>         Sampling rate 4800.  I didn't choose this, it just happened.
> 
>     (b) recording profile adjusted to be closer to (1) but some
>         divergence remains:
>         Avg bitrate 2200, Max bitrate 3200, Sampling rate 4800
>         (Sampling rate cannot be adjusted.)
> 
> 
> Playback systems:
> 
> (i) Mythbuntu with MythTV 0.20 -- suitable for playing back recordings
>     from (1).  Cannot play recordings from (2) since MythTV versions are
>     required to match.  (Transport protocol: Myth)
> 
> (ii) Mythbuntu (2) can act as its own front end.  Cannot play
>      recordings from (1) because the MythTV versions differ.
>      (Transport protocol: Myth)
> 
> (iii) mplayer on a variety of Linux systems (transport protocol: http,
>       NFS, or direct file-system access).
> 
> (iv) AppleTV (MacOSX) running XBMC (transport protocol: UPnP or Myth
>      -- I'm not sure)
> 
> (v) Acer Revo (Atom + nVidia Ion) running XBMC under 64-bit Linux with
>     nVidia proprietary X driver. (transport protocol: UPnP or Myth).
>     (Similar results running XBMC on (2) with an nVidia proprietary
>     driver.)
> 
> (vi) WD-TV live; firmware 1.02.21 and earlier (transport protocol: UPnP or SMB)
> 
> 
> Observations:
> 
> (i) works fine as a frontend for (1) but not (2) (version clash)
> 
> (ii) similarly works fine for (2) but not (1) (version clash)
> 
> (iii) has worked well for (1).  I've used Mythweb to give me a URL to
>       feed mplayer.
> 
>       It did not work for (2a).  It always failed with the error
>       message:
> 	Too many video packets in the buffer: (4096 in 7900000 bytes).
> 
>       Googling lead me to this thread
> <http://www.mythtv.org/pipermail/mythtv-users/2010-March/282720.html>
>       which lead me to play with the recording profile, creating (2b).
> 
>       mplayer works with (2b).  I find this quite mysterious.
> 
> (iv) works well for both (1) and (2)
> 
> (v) works well for (1) but not (2)
>     It seems odd that XBMC on OSX works but not on Linux.
> 
>     The failure mode is:
> 
>     - XBMC doesn't correctly know the length of the recording
> 
>     - playing fails part way through a recording.
>       Sometimes quite early, sometimes as much as an hour in.
>       Sometimes the failure is just a stop, sometimes a constant
>       stuttered repeat happens.
> 
> (vi) fails for (1).  I described this in this thread:
>      <http://www.mythtv.org/pipermail/mythtv-users/2009-December/275129.html>
>      I still have no answers to those questions.
> 
>      Fails for (2) differently.  It starts to play, sound and picture,
>      but after a few seconds the image freezes and the sound crackles
>      and stops.
> 
> Other oddities:
> 
> - why does the WDTV think it can handle recordings from (2a) and (2b)
>   but not (1)?
> 
> - why does the HVR-1600 analog section driver only allow a 48000 audio
>   sample rate?  I think that the hardware is very similar to the
>   PVR-150 that does allow various audio sample rates.
> 
> - mediainfo, applied to a recording from (1) and from (2b), shows no
>   differences that look material.
If that's true then only the container can be the source of the 
problems. ffmpeg and applications relying on it's libraries, most 
includinf mythtv do, has/had 'poblems' in writing compliant containers.
As a test you could remux your source with tsMuxeR/tsMuxerGUI to a 
compliant MPEG-TS container, with MP4Box to a compliant mp4 container 
and with mkvtools to a copmpliant matroska container. Then at least all 
mplayer and XBMC and probably WD-TV Live problems should be solved.
I do have a PopCornHour which is more or less identical to the WD-TV 
Live and is also critical about compliant container formats.
> 
> Is there a tool to check standards conformance of a video recording?
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users



More information about the mythtv-users mailing list