[mythtv-users] Lossless MPEG2 transcoding in 0.25

Wed Apr 4 15:28:58 UTC 2012

-----Original message-----
From:	Joe Nyland <joe at joenyland.co.uk>
Sent:	Wed 28-03-2012 21:48
Subject:	Re: [mythtv-users] Lossless MPEG2 transcoding in 0.25
To:	Discussion about MythTV <mythtv-users at mythtv.org>; 
> On 27 Mar 2012, at 22:44, Joe Nyland wrote:
> 
> > Yeah, you're right: the auto detect option allows me to do an MPEG2 - MPEG2 
> transcode. However, my next stumbling block is the TV will not playback the 
> MPEG2-PS file after transcoding :-/
> > 
> > I'll have to do some more research on why the transcoded files will not 
> playback on the TV. I fear I may need something more than a 'bog standard' 
> transcode after all...
> > 
> > Thank you for your help.
> > 
> > Joe
> 
> Hmm... I 've done some more testing of this. It seems that if I transcode a 
> recording using the auto detect profile suggested by John Pilkinton, I do get 
> an MPEG2-PS file, which as far as I am able to make out IS compatible with the 
> TV I'm working towards - a Panasonic TX-P42G15GB.
> 
> If I browse the UPnP server from the TV, by going into the 'Recordings' folder, 
> select the show/channel/group/whatever to the newly transcoded recording, the 
> TV will not play the file back.
> 
> However, If I copy the recording file to /var/lib/mythtv/video, which is the 
> default location for 'videos' in my storage groups, rescan for videos, then 
> refresh the TV's UPnP list, browse to 'Videos' (not 'Recordings') select the 
> file, the file plays back straight away.
> 
> Some background info which may help:
> - I have ruled out NFS causing an issue: I have copied an example transcoded 
> recording from my NFS recordings directory to a local folder in my recordings 
> storage group (/var/lib/mythtv/recordings/) but I receive the same behaviour.
> - I have checked that file permissions are consistent after copying files 
> around between 'Videos' and 'Recordings' storage groups, so there's no problem 
> with Myth reading the files to serve them up to the UPnP client.
> - The only difference I can see is that when the mpg files are in the video SG, 
> they are presented to the TV as $CHANID_$STARTTIME.mpg whereas when they are in 
> the recordings SG and are thus presented as recordings, they appear as 
> $SHOWTITLE: $SUBTITLE (as you all know). My concern is that the colon is the 
> issue my TV is having with the files in the recordings SG.
> - Gigabit cat5e network connection to the TV (I believe the TV is only 100MB, 
> though)
> - No errors are logged in the backend logs concerning attempted/failed UPnP 
> playback from the client
> - Transcode jobs complete successfully and furthermore, the transcoded files 
> from MythTV play fine when presented to the TV as simple video files.
> - VLC can playback all recordings/videos - again, this proves that MythTV is 
> presenting the recordings in some way that the TV can't handle, with the 
> complication that it's only apparent in the recordings SG.
> - Server specs:
> 	Dell PowerEdge T110II
> 	Xeon E31230 3.2 GHz (Quad core +HT) CPU - 4 cores assigned to MythTV backend 
> server
> 	1GB RAM 1333MHz DDR3 assigned to MythTV backend server
> 	Recordings stored on 3 1TB Seagate drives in md RAID5 - accessed over NFS
> 	Ubuntu 10.04 LTS x64
> 	HDHomeRun HDHR3 as the TV source - UK Freeview, so SD quality
> 	MythTV Version : v0.25-rc-80-g292ac93 (MythBuntu)
> 	MythTV Branch : master
> 	Network Protocol : 72
> 	Library API : 0.25.20120315-2
> 	QT Version : 4.6.2
> 	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_iptv using_ivtv
> 	using_joystick_menu using_libcrypto using_libdns_sd using_libxml2 using_lirc 
> using_mheg
> 	using_opengl_video using_qtwebkit using_qtscript using_qtdbus using_v4l2 
> using_v4l1 using_x11
> 	using_xrandr using_xv using_bindings_perl using_bindings_python 
> using_bindings_php
> 	using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads using_live 
> using_mheg
> 	using_libxml2
> 
> Another side issue, which I feel is worth mentioning, but has only just started 
> so I'm not sure it's related:
> - Since this morning, when testing UPnP with VLC, I have noticed very poor 
> performance playing back files over UPnP - videos and recordings will play 1-2 
> seconds, then stall for ~5 seconds, then play 1-2 seconds and stall, and so on. 
> Again, my initial concern was that this was a latency issue introduced with 
> using NFS, but I eradicated this by moving the same recording file to a local 
> directory in the same SG but still got the same stuttering/stalling in VLC. 
> Furthermore, XBMC also shows the same stuttering when playing back over UPnP. 
> The only way I've been able to restore full performance is to restart the 
> backend service. Later in the day, the issue has reoccurred. I appreciate this 
> does sound like a storage/NFS issue on it's own, but what contradicts this is 
> that I can playback the same recording (or any other recording) no problem from 
> MythFrontend at the same time that the UPnP server/client is stuttering, thus 
> proving that the file IS accessible/readable/can be streamed fast enough.
> 
> So my question is: Has anyone any ideas why my transcoded recordings are 
> playing back via UPnP only from my 'Videos' storage group, and not as an actual 
> 'Recording'? Put another way: Does MythTV do any thing different to the way an 
> mpg file is presented to a UPnP client, when it is from the recordings SG, 
> apart from the obviously different folder structure?
> 
> Any help anyone can give will be greatly appreciated.
> 
> Thanks,
> 
> Joe

Ok, I've performed some more testing on this issue.

- It seems that the TV does not have an issue playing back files with or without a colon in the displayed file name which is sent by MythTV, provided they are served as a video and not a recording.
- The TV does not have a problem playing back files in the Videos storage group, as long as it's MPEG2-PS.
- There doesn't seem to be anything that suggests that anything is failing in the mythbackend logs (attached). There are no errors to suggest invalid requests from the TV.
- Furthermore, there doesn't seem to be any different behaviour in the logs from the TV when attempting to playback from the Recordings storage group, compared to the Videos storage group.

The logs which I have attached were created with '-v all' on mythbackend, so I'm afraid I can't get any more in depth information from the backend.

Does anyone know whether mythbackend does anything special to recordings which are presented to UPnP clients via the Recordings storage group? I've tried to find this out for myself by looking into the current code on Github, but I'm no developer and I can't seem to work out why I'm seeing different behaviour between the two groups.

I appreciate in the grand scheme of things with the 0.25 release coming up, that this isn't really an issue to anyone but me and above all it's the TV that's being fussy, but I'm running out of options. Can anyone help me with this please?

FWIW by backend is now running:

MythTV Version : v0.25-rc-126-g711386d
MythTV Branch : master
Network Protocol : 72
Library API : 0.25.20120315-2
QT Version : 4.6.2
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_iptv using_ivtv using_joystick_menu using_libcrypto using_libdns_sd using_libxml2 using_lirc using_mheg using_opengl_video using_qtwebkit using_qtscript using_qtdbus using_v4l2 using_v4l1 using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_bindings_php using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg using_libxml2

Thanks,

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mythbackend.recordings.log
Type: application/yaffas-filedownload
Size: 4239 bytes
Desc: not available
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20120404/9153c0cc/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mythbackend.videos.log
Type: application/yaffas-filedownload
Size: 7310 bytes
Desc: not available
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20120404/9153c0cc/attachment-0001.bin>