[Wicked0ne]

Hello all. Im running xbmc dharma on fedora 17 linux and have been using xbmc with mythtv for a years now and love it. My setup right now is xbmc dharma and mythvtv 0.24 with a hdhomerun prime cable card tuner using verizon fios for my provider....99% of the recordings are in HD. Im having issues with some recordings...they will start to play but if i fast forward or skip the video player stops and drops me back to the video selection screen. I had this issue a few times in the past and have never found a solution for this and its become very annoying....Here is the debug log from when it crashes...i dont see anything super obvious in it though.

http://pastebin.com/rEkbtq2c

Also here is the output from mediainfo on the file:
mediainfo /OldHDD/MythTVRecordings/1621_20120624215900.mpg
General
ID : 0 (0x0)
Complete name : /OldHDD/MythTVRecordings/1621_20120624215900.mpg
Format : MPEG-TS
File size : 5.28 GiB
Duration : 1h 1mn
Overall bit rate mode : Variable
Overall bit rate : 12.2 Mbps

Video
ID : 6041 (0x1799)
Menu ID : 1 (0x1)
Format : MPEG Video
Format version : Version 2
Format profile : Main@high
Format settings, BVOP : Yes
Format settings, Matrix : Default
Format settings, GOP : M=3, N=15
Codec ID : 2
Duration : 1h 1mn
Bit rate mode : Variable
Bit rate : 11.6 Mbps
Maximum bit rate : 38.8 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Active Format Description : Letterbox 16:9 image
Frame rate : 59.940 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.211
Stream size : 5.02 GiB (95%)

Audio #1
ID : 6042 (0x179A)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Codec ID : 129
Duration : 3s 424ms
Bit rate : 0 bps
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : -513ms
Language : English

Audio #2
ID : 6043 (0x179B)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Codec ID : 129
Duration : 1h 1mn
Bit rate : 0 bps
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : -490ms
Language : Spanish

Text #1
ID : 6041 (0x1799)-CC1
Menu ID : 1 (0x1)
Format : EIA-608
Muxing mode : A/53 / DTVCC Transport
Muxing mode, more info : Muxed in Video #1
Duration : 1h 1mn
Bit rate mode : Constant
Stream size : 0.00 Byte (0%)
Text #2
ID : 6041 (0x1799)-1
Menu ID : 1 (0x1)
Format : EIA-708
Muxing mode : A/53 / DTVCC Transport
Muxing mode, more info : Muxed in Video #1
Duration : 1h 1mn
Bit rate mode : Constant
Stream size : 0.00 Byte (0%)

Menu
ID : 6040 (0x1798)
Menu ID : 1 (0x1)
List : 6041 (0x1799) (MPEG Video) / 6042 (0x179A) (AC-3, English) / 6043 (0x179B) (AC-3, Spanish)
Language : / English / Spanish
SCTE35_PID : 2051

[dteirney]

It's almost certainly related to some problems with mpegts playback support in ffmpeg. More details at http://trac.xbmc.org/ticket/6614#comment:31

I've started re-encoding the recorded mpegts files after they have been recorded using ffmpeg to help try and alleviate this problem. I can share the script that is automatically run as a User Job in mythtv if you are willing to try it. It's not bullet proof as it doesn't always fix the time stamps but we haven't had a problem with videos stopping during skipping for a while now.

[Wicked0ne]

Ah. Yea it seems its something to do with the timeseek or something similar to that. Id love to scope out the script you use...I tried messing around with mencoder/ffmpeg about a year ago to try and fix this...but i just dont know enough about what was wrong and what to do to fix it.

[dteirney]

Below is the script that I have used. It re-muxes the file copying all the streams and attempts to fix the timestamps. The first parameter is the file to copy.

Note that this uses the latest git version of ffmpeg. I had some problems with earlier versions when using the -async 1 attribute.

For more information have a look at http://ffmpeg.org/ffmpeg.html#Stream-copy

Code:

$ cat /usr/local/bin/ffmpeg-mpegts-copy
#!/bin/bash
FILE=$1
COPY=$FILE.ts
#Should try using -vsync drop rather than -async 1 to generate fresh timestamps but that doesn't seem to work in ffmpeg at the moment.
/mnt/drive0/git/ffmpeg/ffmpeg -i "$FILE" -codec copy -async 1 -y -loglevel verbose "$COPY"
if [ `echo $?` -eq 0 ]; then
    let COPYMINSIZE=95*`stat -c%s "$FILE"`/100
    if [ `stat -c%s "$COPY"` -lt $COPYMINSIZE ]; then
        echo "Transcoded file is less than 95% original file size. Needs checking manually."
        exit 2
    else
        rm "$FILE"
        mv "$COPY" "$FILE"
        exit 0
    fi
else
    echo "Failed to transcode $1 using ffmpeg"
    exit 1
fi

Obviously you'll need to change some parts to work with your environment, e.g. wherever you put the git version of ffmpeg.

My suggestion would be to test this script on some recordings that you know are broken and then see if they work. Just copy the files to somewhere XBMC can play them off disk and run the script there and then test again in XBMC. You could comment out the rm and mv parts and just test the .ts file that is created.

If you come up with any improvements be sure to let me know.

Once it's working you can set it up as a User Job in MythTV and then configure all recording schedules to trigger that User Job. It's very fast to run, especially compared to the commercial skip detection.