Improving commercial break skip support for MythTV

**dteirney** · 2012-05-08 14:42

I've heard that a number of people may be experiencing commercial skips happening in the wrong place in XBMC where it works correctly in mythfrontend.

If this has happened for you are you able to post:
1) A link to a full debug log opening the recording that has the incorrect skip behaviour (please just that file - full debug log files are long enough as it is).
2) A list of the time periods that the commercial break should have been (to the nearest 5 seconds should be fine)
3) What sort of tuner the recording was recorded using, e.g. DVB-T, Analog, Cable via USB Tuner.
4) Whether you know if there are any frame rate changes in the playback, e.g. I've heard that some stations play commercial breaks at a different frame rate to the broadcast content. If this happens, unfortunately, there is unlikely to be a workaround.

If it's possible to improve the behaviour I will. However, mythbackend stores frame markers for the commercial break locations and XBMC needs time markers to perform seeking so there is a little bit of heuristic black magic to get the right frame rate to use to convert from the frame markers to timestamps.

For interest sake as well, consider having a look at the advanced EDL settings in XBMC to help remove false positive commercial breaks. http://wiki.xbmc.org/index.php?title=Use...#.3Cedl.3E

And for those that are also interested I've already submitted a patch that appears to resolve the 10 second hang that is experienced when a commerical break is skipped.

**dteirney** · 2012-05-13 11:20

No takers so far so I'll relax the requirements somewhat. If you are having problems with commercials being skipped at the wrong time please post a debug log showing playback of the recording that is problematic.

tsp42 · 2012-05-13 13:30

If it is any help the mythtv MySQL table recordedmarkup contains the framerate of the recordings. It would be interesting if the people that experience problems could post the content of that table to see if mythtv stores when the framerate changes in the recordings.

**dteirney** · 2012-05-14 10:28

(2012-05-13 13:30)tsp42 Wrote: If it is any help the mythtv MySQL table recordedmarkup contains the framerate of the recordings. It would be interesting if the people that experience problems could post the content of that table to see if mythtv stores when the framerate changes in the recordings.

Do you mean this table? http://www.mythtv.org/wiki/Recordedmarkup_table

That table stores the actual frame number for each type of mark that gets stored. The offset column (apparently) used to contain the associated timestamp but that was deprecated ages ago and was empty when I looked at using it several years ago.

tsp42 · 2012-05-14 11:24

(2012-05-14 10:28)dteirney Wrote:
(2012-05-13 13:30)tsp42 Wrote: If it is any help the mythtv MySQL table recordedmarkup contains the framerate of the recordings. It would be interesting if the people that experience problems could post the content of that table to see if mythtv stores when the framerate changes in the recordings.

Do you mean this table? http://www.mythtv.org/wiki/Recordedmarkup_table

That table stores the actual frame number for each type of mark that gets stored. The offset column (apparently) used to contain the associated timestamp but that was deprecated ages ago and was empty when I looked at using it several years ago.

Yes at least in my version 0.24 it contains all kind of information about the recordings. The rows with type == 32 contains the framerate.
See https://github.com/MythTV/mythtv/blob/ma...ramtypes.h
Here is the actual commit that added the frame rate to the markup table: https://github.com/MythTV/mythtv/commit/...65f8cec2e5

**dteirney** · 2012-05-15 02:54

Interesting. Just out of interest how many 32 entries does it have for each recording?

The automated seeking in the XBMC player is time based. Without being able to calculate the correct time for the start and end positions of the commercial breaks before the playback starts everything gets messy. If someone knows some magic to calculate the actual playback time that corresponds to a frame marker using whatever information is currently in the database that might be an avenue to explore. Mythfrontend obviously manages (maybe) but I believe it's player uses the recordedseek table for some information.

The current approach will never work properly for recordings that have a change in frame rate in them. Tracking frame rate changes in the player will not help because as soon as a manual skip is done you don't have any idea what was skipped over so the calculations could be all up in the air again.

tsp42 · 2012-05-15 22:38

It only has one entry per recording but the frame rate doesn't change during the recordings.
According to the commit previous linked every frame rate change should be included in the table.

The following pseudo-code could be used to convert the frame marker to times in seconds:

Code:

//Parameters

//framemarker: frame marker to convert to time

//framerates: array of frame rates from the recordedmarkup table

//marks: matching array of frame marks from the recordmarkup table

//length: length of the two arrays

//

//Retval: time in seconds corrensponding to the framemarker

time_t markerToTime(long long framemarker,int framerates[],long long marks[],int length)

{

    time_t retval=0;

    if(length==1) //constant framerate

        return(framemarker/framerates[0]);

    for(int i=1;i<length;i++)

    {

        if(framemarker>=marks[i]) 

            retval += (marks[i]-marks[i-1])/framerates[i-1];

        else

            return(retval + (framemarker-marks[i-1])/framerates[i-1]);

    }

    return(retval);

}

**dteirney** · 2012-05-16 00:32

I'll recheck the mythbackend code that is used to calculate the frame rate in the first place. If it's doing the same as XBMC, which I think it was when I initially looked, then the frame rate would probably still need manipulation like it is using the current heuristics within XBMC.

The equivalent frame rate that was used by mythcommflag is what is needed, not what is reported in the video stream header information.

Having said that if the database will indeed contain an entry each time the framerate changes that would help. The heuristics could just move into the calculation.

tsp42 · 2012-05-16 00:46

Looks like MythTV scans each transport stream packet for the frame rate while saving the recording:
https://github.com/MythTV/mythtv/blob/ma...corder.cpp

varneyb · 2012-06-11 03:19

(2012-05-08 14:42)dteirney Wrote: 1) A link to a full debug log opening the recording that has the incorrect skip behaviour (please just that file - full debug log files are long enough as it is).
2) A list of the time periods that the commercial break should have been (to the nearest 5 seconds should be fine)
3) What sort of tuner the recording was recorded using, e.g. DVB-T, Analog, Cable via USB Tuner.
4) Whether you know if there are any frame rate changes in the playback, e.g. I've heard that some stations play commercial breaks at a different frame rate to the broadcast content. If this happens, unfortunately, there is unlikely to be a workaround.

1) I'll have to work on getting you a log, but I know that I do get the following WARNING:
WARNING: ReadComskip - Frame rate not in Comskip file. Using detected frames per second: 29.970

2) I have found that if I use a skip list generated by comskip.exe instead of mythcommflag, it works. For E02 of Unforgettable:
Here is the mythcommflag skip list:
FILE PROCESSING COMPLETE
------------------------
31137 36371
47736 53922
68679 72980
88667 92785

And here is the comskip skip list:
FILE PROCESSING COMPLETE 107718 FRAMES AT 2997
-------------------
1 206
10030 15825
36923 42438
56113 62638
80338 84924
98699 107718

3) Over the air (ATSC) tuner (HDHOMERUN)
4) I don't know, but I know that if I use the comskip list, I get the skips in the right place. However, there is a substantial delay (15-20 seconds) when it skips during which XBMC is completely unresponsive. This has happened with EDEN both on XBMCBUNTU and Windows Vista (I did not have this problem with Dharma on Vista).

tsp42 Senior Member Posts: 222 Joined: Aug 2011 Reputation: 11 Location: Denmark	2012-05-13 13:30 Post: #3 If it is any help the mythtv MySQL table recordedmarkup contains the framerate of the recordings. It would be interesting if the people that experience problems could post the content of that table to see if mythtv stores when the framerate changes in the recordings. Libcmyth MythTV addon for xbmc-pvr [source] [forum thread]
	find quote

tsp42 Senior Member Posts: 222 Joined: Aug 2011 Reputation: 11 Location: Denmark	2012-05-16 00:46 Post: #9 Looks like MythTV scans each transport stream packet for the frame rate while saving the recording: https://github.com/MythTV/mythtv/blob/ma...corder.cpp Libcmyth MythTV addon for xbmc-pvr [source] [forum thread]
	find quote