All object ids reset!?

[Slugger]

Sometime after Jul 24, 0:07 EDT all the object ids in my wiz.bin were changed. This last recording had MediaFile ID 10016738 then the next recording had media file id 164157. Is this expected behaviour or is this a side effect of upgrading to 6.6.1? My only problem is that all the existing objects have had their id numbers changed so in my other plugins where I refer to a favourite by id number I now get a null pointer in return because Sage has decided to renumber all the objects. If the id counter needed to be reset for some reason then that's fine, but why renumber existing objects? Why not just reset the counter for newly created objects? Is there anyway to get the previous id number of an object or is any reference to an object by its id simply invalid now?

[Opus4]

IDs can be resequenced when SageTV needs to do so, so it is expected.

- Andy

[Slugger]

Existing objects (specifically favourites) are also renumbered by design during this process? Is there anyway to get the old id so external references (i.e. references made by plugins) can also be remapped? Undoubtedly, this unannounced, in the sense that plugins have no way of being told that it is happening, remapping by Sage must break quite a few plugins (I know if breaks some of mine).

[GKusnick]

Yeah, I get burned by this periodically as well, and it's pretty annoying when it happens. In my experience it can happen not just when you upgrade to a new version, but potentially any time you restart the service. I have yet to find a good workaround; unfortunately there just doesn't seem to be any sort of long-term invariant way for third-party apps to refer to database objects.

If renumbering is unavoidable, it sure would be nice if there were some kind of hook or callback function that could be passed a Map from old ID into new ID for all renumbered objects. Or more crudely, just dump all the old->new ID pairs to a text file and let plugins check the timestamp and update their data files appropriately.

At the very least, there should be a note in the documentation for API methods such as GetFavoriteID, GetMediaFileID, et al. indicating that the IDs are not stable long-term.

[Narflex]

There's another solution which should realistically eliminate the need for this to occur. We'll change the rollover point to be 500,000,000 instead of 10,000,000 so it'll take 50 times longer to occur (which should mean it'd take about the lifespan of a person to occur).

[Slugger]

Rolling over at 500M will definitely suffice. Doing so means you won't hear from me about this again until approximately July, 2109. I'd say I won't be around by then, but I'll put a little faith in modern medicine and say there's an outside shot (slim, but not 0%).

Is this rollover change something we can expect in an upcoming beta or further down the road?