(2012-06-11 03:19)varneyb Wrote:(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
And here is the comskip skip list:
FILE PROCESSING COMPLETE 107718 FRAMES AT 2997
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).
1) The detected frame rate of 29.97 matches the frame rate in the comskip.exe generated file, e.g. the 2997 part. So that means that the commercial skip tools are finding different commercial break locations. What commercial detection method are you using in mythbackend? I use Logo Detection for New Zealand transmissions. All the other methods were hopeless.
2) You shouldn't get the warning re the Framerate not being in the comskip file for that file. 2997 means 29.97fps. How are you playing those recordings?
4) There is a known issue that is currently being worked through for the skip delay. https://github.com/xbmc/xbmc/pull/944 (still needs a lot more work with help from another XBMC developer to sort out what introduced the problem).