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? > 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. -Tom ------------------------------------------------------------------------------ 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/
