Tue Nov 17 13:52:17 UTC 2009
watched flags are left unchanged, as are the commflag and custlist
entries in the recordedmarkup table. So it seems there is a basic
assumption that frame numbering remains consistent before and after
transcoding. (This assumption would surely be invalid if the
transcoder did something like change the frame rate.) Given that
assumption, it should be pretty simple to use the cutlist to
accurately calculate the new bookmark. Of course, if what you say is
true and the bookmark is in general invalid even when no cutlist is
applied, then the no-cutlist branch of the code must be wrong.
Now, even if the bookmark could be properly translated, there's still
a problem in that you have to somehow figure out whether the bookmark
corresponds to the original file or the transcoded file. I think you
could make a solid guess by looking for a "player" record in the
inuseprograms table and comparing its lastupdatetime field against the
time that the new filename was set in the database.
> Resetting the watched flag is a judgment call [...]
Thanks for the explanation. Personally, I'm less concerned with the
watched flag, which has only two possible values and is easy to
manually set right, and more concerned with the bookmark, which is far
more exasperating when it goes away.
More information about the mythtv-dev