Tom Metro wrote: > Mike Holden wrote: >> There's an old thread at >> http://www.nabble.com/Mythtv-commercial-skipping-tt20333293s24862.html#a20333293 >> which tries to discuss this issue, and it would appear it was resolved >> for >> that user, but I have a current build and it doesn't work. > > In that thread the user submitted a patch. Have you applied that patch? > Have you checked git to see if that patch made it into the code?
The 2nd mail in that thread says that a patch was committed on Oct 9 which fixes this issue for DVB-T, hence I have not pursued adding the patch myself (yet). That specific patch however is not in git, as I have a fresh checkout of the current repository. I am looking to get a local copy build running, but haven't got there yet. I'm getting some errors in make mvp which I am attempting to resolve. >> Could somebody who is familiar with the code in >> cmyth_mysql_get_commbreak_list please explain the thinking behind the >> mysql query used there, especially around the FLOOR and /15 stuff? > > Here's another message showing the SQL tweaks to support DVB-T cards: > http://www.nabble.com/commskip-update-plus-more-tt13437281s24862.html#a13477610 > > See this thread for discussion of the card types and the corresponding > divisors: > http://www.nabble.com/determine-type-of-mythtv-recording-tt19263171s24862.html#a19263171 > > > Michael Drons wrote: >> The commskip functions were never written for a DVB-T card type. There >> were written for an IVTV card type. The entries in the DB are very >> different based on the card type that did the recording. >> >> What needs to happen is the code needs to understand the difference >> between the different cards. > > This is one of those places where the pitfalls of directly accessing the > database are really apparent. > > I see in a message from January 2007 Michael Drons wrote: > http://www.nabble.com/MYTHTV-Bookmarks-help-tt11795275s24862.html#a11795275 >> I am working on mythtv bookmarks and I am getting >> close. I query for the bookmark and it returns the >> mark value from the recordedmarkup table. My issue >> is that I need to take that number and divide by 15 + >> 1 to get the mark value that is in the recordedseek >> table. The associated offset is the seek to value >> that is needed. The question: Is there a QUERY >> command in mythtv protocol that gives this value? or >> Do I need to write an SQL command. The easy answer is >> SQL and it appears to be what the commbreak code does. >> Is it because there is no protocol message available? > > It's too bad there isn't really any overlap between mvpmc developers and > MythTV developers, as the right solution (probably stating the obvious) > would be to extend the MythTV protocol to provide the needed > information. That way mvpmc can remain blissfully ignorant of details > like the recording card type. > > Of course that's a bit more work to implement, and given the choice > between a hacked commskip and no commskip, I'd still take the hacked > one. Also, if the MythTV developers had built a comprehensive protocol > to support their native client, instead of letting it delve into areas > it shouldn't touch, the functionality mvpmc needs would already be there. > > Going forward maybe refactoring the code to involve some changes on the > MythTV side of things would be the way to go. Agreed. We ought to be using existing MythTV protocols where possible. I saw another thread about a patch that had been submitted to use some additional Myth protocols at http://www.nabble.com/Fw:--mythtv---PATCH--protocol-extension-patch,-no-generic-SQL-td11792015s24862.html which would include protocols for commbreak, bookmarking, settings and cutlist. This would appear to me to be the best approach - let Myth worry about the format and give us the data we need. -- Mike Holden http://www.by-ang.com - the place to shop for all manner of hand crafted items, including Jewellery, Greetings Cards and Gifts ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Mvpmc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mvpmc-users mvpmc wiki: http://mvpmc.wikispaces.com/
