id summary reporter owner description type status priority milestone component version severity resolution keywords cc mlocked 2293 Upgrading from dbver 1128 can cause wierd bookmark behavior perveilerj@… stuartm "The upgrade from dbver 1128 changes the meaning of recorded.bookmark. It appears to have previously held a unsigned long long as a string (an offset to the bookmark, maybe?), but after dbver 1128 the offset moves into recordedmarkup.mark and recorded.bookmark becomes a tinyint intended to hold 0 or 1. After upgrading to r10954 from 0.19-fixes, I noticed that some old recordings with bookmarks would not show their bookmarkedness in mfe or mythweb, but on pressing play would start unconditionally at the bookmark. Inspection of recorded.bookmark shows these shows with a value of 127. I can't find anyplace in r10954 that could cause this value to be anything other than 0 or 1, but I believe the conversion of the bookmark field to tinyint caused a tuncation, resulting in a 127. My database is already upgraded, so unfortunately I can't reproduce the truncation. Altering a new table for experimental purposes shows that mysql will truncate this way, however. Since the current ProgramInfo::getProgramFlags() treats bookmark values != 1 to mean no bookmark, you get the symptoms I've described. I can see 3 possibilities for dealing with this: 1) Do nothing. It only affects old recordings, and you can always rewind if you don't want to start at the bookmark. 2) Patch dbcheck.cpp to change all non-zero rows in recorded.bookmark to '1' after they've been inserted into recordedmarkup 3) Change ProgramInfo::getProgramFlags() to treat recorded.bookmark != 0 as having a bookmark. I can generate the patch, just let me know what you prefer. Assigning to stuartm as per discussion on the dev list. --Jack " defect closed minor unknown mythtv medium fixed 0