GUI_MSG_UPDATE_ITEM msg from https://github.com/xbmc/xbmc/blob/master/xbmc/utils/SaveFileStateJob.h#L92 will not work correctly when old item in items vector has startOffset set to STARTOFFSET_RESUME and new one has set it 0 (it won't update item because CFileItem::IsSamePath will return false).
This is more request for comments than pull request (my commit is just dummy fix that work in my case, but propably will fail somewhere else). We could have flag to determine if we need to compare startoffset to differentiate items - f.e. add some property to fileitems when creating them from cuesheet (and anything similiar). Any thoughts on this?
Yeah - agreed that we need a way to differentiate items. I'm not sure the best technique for cue sheet items, but clearly using a separate value that's also used by something else (start offset) is not working. There was some comments on this in the cue sheet stuff in #840. Essentially to give a separate match path for those items that are actually differentiated but otherwise have the correct path.
So set path to f.e. "path_to_file.ext?startOffset=XXX" and when we start playback strip off additional params and read startOffset? Wasn't yet looking at code at all, just wondering what needs to be done.
I'm not sure. I suspect that will cause issues all over the show, however. As far as I'm aware, cue sheet handling is OK, as-is, so maybe just have m_matchPath be used in IsSamePath() and have cue sheet items set that? Just have to make sure it's set everywhere it needs to be (Cue stuff + musicdb of cue's most likely). This way we have a well-defined member that's used just for matching items and nothing else, so that other uses of m_lStartOffset don't collide.
how about we simply set a prop ?
I started doing it this way (https://gist.github.com/c99dfbbc15df4e7456b9) but as I didn't have neither handy cue stuff nor more time to spend on it I don't know if it's actually working or where I would need to make more changes (hints always welcomed). This is yet another postponed work from me waiting for my "free time and will"... TBH after pike's complains about cue "shit", I'm affraid to dl any samples and play with them ;)
compare dedicated item_start property instead of multi purpose starto…
…ffset member to determine if FileItem represents same item
This is aproach of setting dedicated "item_start" property to differentiate items (well, songs now as we don't support videos) in single file, seems to be working fine (as in no regressions for #840). Tested with "1 large audio file album + 1 .cue with indexes" both from file mode and from library.
It's fine, though I wonder whether having a more generic compare path property might be more useful - more of a PITA to set up though if you use a property rather than a member as you need to format it up all over the show - maybe best just to leave it as this for now and we can extend later if needed.
Feel free to pull.