I'm looking for a solution toward a patch for commercial skipping in Myth's uPnP server. Originally, I thought that an .m3u playlist would be the way to go, with each entry being a segment of content that comprises a track for the player. The next chapter button would provide semi-automatic commercial skipping, which the user could control. But the Link Theater would likely pause as the next segment is buffered, but since it's during a commercial break, it's not that distracting. However, most users would probably prefer a more continuous streaming effect.

I found that you can request the entire file from Myth's uPnP server, which
will stream it out in response to a URI request like the following:



(this works, even from a browser), but, there is no way to specify a byte
range in a URI to indicate that the client wants only part of the content.
Byte ranges are part of the HTTP 1.1 specification, and are passed along
outside of the URI in the header of the request. Myth's uPnP server
provides partial content using the byte range header in the request, and the Link Theater uses these byte ranges to fast forward or rewind.

Therefore, I am dead-in-the-water with my idea about using a playlist, like
a .m3u file, to get segments of content from the Myth uPnP server (unless I modify Myth's uPnP server to accept another parameter like off=, as was done in the Wizd server). Likewise, even if Myth's uPnP server were modified to provide output denoting chapters for a video playlist (by serving in the proprietary format that causes the Link Player to recognize the chapters), the Link Player could not request segments of content from Myth's uPnP server in the URI requested by the Link Player. But I want to keep with the standards, and not get hardware-specific.

The only alternative that fits this criteria would be to do as you suggest for a more integrated solution -- to have the backend, as it is serving up the file content, look at the commercial skip list and omit those ranges from the content seamlessly. The trouble is the false positives that Myth marks. If program content is cut out, then you'd want to turn this feature off, or rewind, to see what you missed. Perhaps a better solution is to have the backend respond to a next chapter button, and skip over the marked commercial content. The trouble with that is that it can't be done in the lower level HTTP protocol, for the reasons I expressed above. Perhaps commercial skipping could be specified as chapters in a higher-level protocol, like uPnP. Alas, I'm not that familiar with it, and it will require that I spend much more time learning the uPnP protocol to see if this is even feasible.

Does anyone have any suggestions?

TIA,

Rob

_________________
Backend: 2.4GHz Celeron; 512Mb RAM; 130Gb IDE HDD; DVD-RW
Hauppauge Win-PVR 250; DViCO Fusion HDTV Lite
KnoppMyth R5E50 -> SVN
Frontends: Buffalo Link Theater, Mac Mini Intel duo core & Xbox

An update. After reading the upnp content directory server specs especially section 2.8.9.2, I learned that a server must have the ability to serve content with byte range offsets in order to provide a segment of content. Accordingly, I modified httprequest.cpp in libmythupnp, to accept a parameter "bytes=".

After successful compile, I browsed the mythconverg database using webmin's built-in MySql server, found the tables recordedmarkup and recordedseek. I found the type "5" marks denoted the end of a detected commercial, but the mark units are frames. I found recordedseek provides byte offsets for keyframes only. Since a keyframe is generated approximately every 15 frames, I divided the mark found in recordedmarkup by 15 to reach the keyframe marked in recordedseek. I then fed the byte offsets as bytes= parameter for the url in my newly-minted uPnP server, and I watched a segment of content, ending at the end of the detected commercials, in Windows Media Player, which was launched by my browser.

Next, by hand, I created an m3u file with the urls corresponding to the segments, ending at the end of the detected commercials. I served this .m3u file with Wizd (since Myth's server does not yet support m3us), and found that I could hit the next chapter button on my Link Theater when the commercials started, thereby skipping over to the next segment of the program!

_________________
Backend: 2.4GHz Celeron; 512Mb RAM; 130Gb IDE HDD; DVD-RW
Hauppauge Win-PVR 250; DViCO Fusion HDTV Lite
KnoppMyth R5E50 -> SVN
Frontends: Buffalo Link Theater, Mac Mini Intel duo core & Xbox

My next step in this process is to create a new method for mythbackend, in mythxml.cpp, that will generate the .m3u file in response to a URL query for the recording. I note the following email concerning marks in the recordedseek table:

http://www.gossamer-threads.com/lists/mythtv/dev/250020?do=post_view_threaded#250020

Consequently, I added the new method to autogenerate .m3u content for recorded programs, which is invoked by, for example:



One problem I can't seem to figure out is, unlike the GetRecordings method, when I provide the exemplary URL in my browser, it does not attach the .m3u extension to the method name when saving as a file. Someone might know how to fix it -- it's currently just an annoyance.

I had to modify yet again the code for fast-forward/rewind too, so that it would be relative to the start of the segment. I completed troubleshooting this evening. At least now we have a bare-bones way to generate .m3u's that can permit commercial-free viewing.

Time to check this stuff into svn. I've created ticket 3580 for the patch.

Next and last step is to modify the content directory server, to provide a listing of autogenerated playlists. This will be a while, because I need a break.

_________________
Backend: 2.4GHz Celeron; 512Mb RAM; 130Gb IDE HDD; DVD-RW
Hauppauge Win-PVR 250; DViCO Fusion HDTV Lite
KnoppMyth R5E50 -> SVN
Frontends: Buffalo Link Theater, Mac Mini Intel duo core & Xbox

Good job. Are you backporting to -fixes as well?!

Not sure I quite understand your question, which sort of reveals my innocence regarding the various flavors of Myth.

I created a diff from the trunk SVN version, which is what I've currently been using. If you're asking me to create a diff to the release-0.20-fixes branch, I guess that would not be that much of a problem at all. What advantage does that yield?

_________________
Backend: 2.4GHz Celeron; 512Mb RAM; 130Gb IDE HDD; DVD-RW
Hauppauge Win-PVR 250; DViCO Fusion HDTV Lite
KnoppMyth R5E50 -> SVN
Frontends: Buffalo Link Theater, Mac Mini Intel duo core & Xbox

Well, I've tried, but failed. I have a new patchfile submitted under ticket 3580, and can generate the new menu of commercial flagged recordings, but I'm running into trouble with two issues:

1. object.item.playlistItem appears to be unsupported, either by my player or by the server. When I change the CDS object from videoItem to playlistItem, the items no longer appear on the player's list when browsing the contents of the Flagged folder. I triple checked the format of the upnp packet to ensure that it met the spec.

2. playlist Resource URLs appear unsupported. Since I could not get the playlist up on the menu, I tried changing the resource from GetRecording to GenM3u, but the player would not play the tracks. The output from GenM3u can still be saved into a .m3u file and played via Wizd, but this is not our objective.

Perhaps another set of eyes can detect the trouble, but for now, I've commented out this functionality. At the very least, we can create trackfiles from recordings, generate .m3u content, but can't play them with Myth's upnp server. The only other tactic I can think of is to save the .m3u content into a file, then see if we can serve the file -- my only other avenue of experimentation until I'm completely dead in the water.

_________________
Backend: 2.4GHz Celeron; 512Mb RAM; 130Gb IDE HDD; DVD-RW
Hauppauge Win-PVR 250; DViCO Fusion HDTV Lite
KnoppMyth R5E50 -> SVN
Frontends: Buffalo Link Theater, Mac Mini Intel duo core & Xbox

I had a dream last night of a different way how to do this -- pretty sick, but I was dreaming in SQL. Funny thing is, IT WORKS! I submitted the patch in ticket 3580, and now am living in video nirvana.

Happy Penguin

_________________
Backend: 2.4GHz Celeron; 512Mb RAM; 130Gb IDE HDD; DVD-RW
Hauppauge Win-PVR 250; DViCO Fusion HDTV Lite
KnoppMyth R5E50 -> SVN
Frontends: Buffalo Link Theater, Mac Mini Intel duo core & Xbox

nice job!!!

impressive ingenuity! That's why open source software is such a good idea, but of course it works so well thanks to the people like you who participate.