[mythtv-users] Lossless MPEG2 transcoding in 0.25

[Joe Nyland]

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