[mythtv-users] Internal player crashes during HDTV playback on specific recordings

[Michael T. Dean]

On 03/02/2009 12:50 PM, Darren Hart wrote:
> On Mon, Mar 2, 2009 at 9:26 AM, Michael T. Dean wrote:
>   
>> On 03/02/2009 11:24 AM, Darren Hart wrote:
>>     
>>> Well, judging from how other players handle it (mplayer and xbmc both
>>> can play it without crashing, but there is some solid evidence of
>>> stream corruption even then) I doubt the stream is 100% valid.  Still,
>>> Myth should be able to cope and continue playing as the other players
>>> do.  I'll look into cropping the video and posting on my site (I have
>>> plenty of space).
>>>
>>> Thanks for the input.
>>>       
>> (Haven't read the whole thread, but...) Yes, Myth /should/ handle it better,
>> but note that the decoding/playback code in 0.21-fixes is old and what's in
>> trunk has been updated significantly since then.
>> Unfortunately, as people find new and interesting ways of breaking the specs
>> (or as stream corruption causes new and interesting problems not seen before
>> the version you're using), it takes time to get code updated /and/ pushed
>> out to users.  And, since the changes introduce a /lot/ of instability,
>> those "new features" (ability to handle new types of corruption) don't get
>> pushed down to the stable -fixes branch.
>>     
> I didn't mean the above as a negative criticism, hope it didn't come
> across that way.  I do understand the issues surrounding release
> engineering.
>   

Yeah, I didn't see it as a criticism.  I just wanted to respond to 
mention some of the reasons why Myth's player may not be "as up-to-date" 
as some others (as well as why comparing MPlayer or xine or ... to 
Myth's internal player is often comparing apples to old apples).

>> Your MPlayer (and I'd assume xbmc) uses much newer libraries, so it has more
>> fixes.
>>
>> So, if you /must/ have a working setup now, either:
>>  a) use some external player (such as MPlayer) to play back the recording
>> (most preferred solution),
>>     
> Is there a way I can do this at play time?  I really want to use the
> internal player most of the time.  Is there anything like a "Play with
> Mplayer" ?  I haven't seen it...
>   

You would move the recording to MythVideo and then play it--based on 
file extension--using an external player.  Note that GNU/Linux isn't as 
brain-dead as a certain popular "operating system," so the extension is 
only a part of the filename and is /not/ required to in any way reflect 
the content of the file.  Therefore, you can simply move the file to 
MythVideo directories and put some random extension on it--even 
"<filename>.play-in-mplayer" and it will work fine (except, of course, 
if you try to play the file in that other popular "operating system").

Ironically, there's even a patch for trunk by Robert McNamara that 
allows you to automatically move a recording to MythVideo from the Watch 
Recordings page.  :)  Unfortunately, it wouldn't port to -fixes well/at 
all.  However, if you have to do this a lot, you could easily do so with 
a script run by a user job for any recording rules that record affected 
shows.  You'll need to copy the recording (renaming it as appropriate) 
and then scan for new videos, and then ask the backend to delete the 
recording (not the video copy).  Writing such a script using the Perl 
bindings would not be very difficult (once you learn the bindings, of 
course ;).

Or, you could even have a Storage Group specifically for these shows 
that writes to the MythVideo directory, so you don't have to actually 
move the recording, but just rename it and "touch" the old filename (so 
the backend has something to delete).

If you only have an occasional recording to worry about, it's probably 
easier to just exit mythfrontend and use a terminal to invoke mplayer 
/gmplayer from the command line--especially if you use mythrename.pl 
--link to create a directory of links that provide easy to use 
filenames.  (Don't use it without --link, though.)

>>  b) as Yeechang suggested, transcode the recording(s) to some other format,
>> possibly with some external transcoder, making a recording that Myth can
>> play (most CPU/power cost to you, as well as inducing a large delay between
>> recording and watching shows), or
>>     

This may integrate very well (possibly better than the above if this 
happens with a lot of recordings), too--and would likely be easier and 
allow you to continue using the Internal player and not have to worry 
about deleting (and, therefore, choosing whether to allow re-record or 
not until after you've watched the show).  There's also a /lot/ of 
information about automatically transcoding recordings using 
mythtranscode or external transcoders on the wiki.

>>  c) subscribe to -dev and -commits list, read all the messages on those
>> lists (as well as a /lot/ of the archived messages that have gone to those
>> lists since 0.21 was released a year ago), then update your system to use
>> trunk (noting that you can not go back to -fixes after trunk), configure
>> trunk properly (making sure that you follow up any issues on the -users
>> list), and test the recording with trunk /and/ keep following/reading the
>> -dev and -commits lists (most work for you).
>>     
> Yeah, I may try this on a laptop or something just to see if it can
> play the stream, but from what I've read it isn't a good idea to run
> trunk on my primary myth installation unless I am prepared to spend a
> lot of time working with the community on issues.  And while I'd enjoy
> it, I can't make the time for it right now.
>   

Right.  MythTV stable/-fixes is a DVR (Developer Video Recorder) for 
people who are willing to tinker.  MythTV trunk is a responsibility.  :)

Chances are since the file plays correctly in MPlayer (which uses newer 
ffmpeg libs than MythTV 0.21-fixes), it will play fine in 0.22, when 
released.  Therefore, you can just wait until 0.22 is released--using 
the workaround, above, until then--and if it doesn't play in 0.22 when 
it's first released, then submit a ticket with a (small) sample file 
that shows the issue.  Since when the new stable version is released, 
its ffmpeg libs are the same as those in the trunk version at that time, 
that's the best time to report playback issues.

>> And, please do not submit a ticket until you have tested playback in MythTV
>> trunk or /at least/ in the current SVN version of ffmpeg (the player,
>> unrelated to Myth--if you have questions about how to do this, please follow
>> up with questions here).  If it works in either of those, we don't want the
>> ticket and playback will likely be fine in 0.22 (when ready).
>>     
> I'll look into this, will take me some time, but I'll reply here if I
> need help and with the results of course.
>
> If I've understood you correctly, you don't feel a fix for this issue
> is a candidate for the .21-fixes series?

Likely not--unless you or someone using -fixes comes up with a patch for 
it (and it's not too invasive).  The developers will be concentrating 
their efforts on trunk and since trunk's code is so different from 
-fixes code at this point, it's likely that playback will be wildly 
different (likely even work) on trunk.  (And, as mentioned, the current 
playback/decoding code in trunk can not be backported to -fixes--if one 
tried to do so, they'd likely have a "stable" version of Myth that's 
less stable than trunk itself, so they'd be better off just committing 
to running trunk).

Mike