[User 191275]

I've been working on a video add-on and wanted to keep track of the playcount and "partially watched" states, to make it easier for users to know what they've already seen (or what they're partway through watching). I noticed that, at least in Frodo, this information is stored in the database. For instance, if you watch half of a video in your add-on and then stop, XBMC will prompt you to resume from where you left off the next time you play it. This is great, but it doesn't show the play icon in the list, so it's hard to know which video you watched partway through. I find myself trying a bunch of videos until I find the one that XBMC prompts me to resume. Likewise, XBMC doesn't put checkmarks next to the videos you've finished.

I looked at the SQLite database and it seems that XBMC is tracking all of this info already: the files table shows the playcount and last-played date and the bookmarks table shows the resume point. However, when adding the ListItem to XBMC, it doesn't pull any of this info in. There's also no easy way to get that info yourself, since the JSON-RPC command "Files.GetFileDetails" doesn't work for HTTP files. I can get this information by running the right SQL queries on the video database, but we're not supposed to do that...

I think there should be a way to have XBMC automatically fetch this info when you add the ListItem to the list, since XBMC already stores all of this information anyway. It would also work if you could add a flag to request that XBMC look up the URL in its database. I just don't think add-on authors should need to run a JSON-RPC command to fetch the info and set it themselves.

EDIT: Another thing I just noticed is that the database records for HTTP videos are removed when running "Clean Library" from the Settings (although the corresponding entries in the paths database aren't cleared when they're not used anymore). That might pose an additional difficulty for users if they clean their libraries often.

[User 191275]

If this is something that the XBMC team actually wants to add, I'd be happy to help write the patch. I think it would be a pretty great feature, but I'm not sure what the best way to implement this would be. If there's a better place for me to put this so that the XBMC folks can comment on it, let me know.

[Bstrdsmkr]

I think they usually take a "patch first, receive questions later" approach. If you write the patch and submit a pull request it'll get the appropriate eyes

[Ned Scott]

Question: has anyone actually said why we can't allow add-ons to read (not write) the SQL DBs? Other than "that's just the way it's been". It's not that I doubt there is a good reason, it's that no reason seems to have been properly documented. It's also possible that there are rare exceptions which could be made, like this one for Gotham (any patch would likely be considered a feature addition, and Gotham is now in feature freeze).

[User 191275]

Directly accessing the DB would probably make it harder to deal with upgrading your add-on to work with newer versions of XBMC that change the table layout. I wrote some code that directly accesses the DB (read-only) just for personal use, and everything works ok, but in the long run, I think this is something that could be (semi-)automatic. That would be less work for me and other add-on devs; all the video add-ons that wanted this would probably have to do the same things anyway.

It probably makes sense that a patch to do this automatically wouldn't land in Gotham, since there are some important questions to figure out, like what should happen if the add-on sets a field that the DB already knows about. For instance, I can get the duration of a video before I load it, but after it's loaded by XBMC, I'd rather grab it from the streamdetails DB, since that value is more accurate. However, other add-ons might want to set the duration to override the streamdetails value.

[Ned Scott]

Well, it might be worth contacting the add-on mailing list about a specific exception just for Gotham and just for your add-on, with the explanation that a non-DB-reading solution is being investigated for post-Gotham. No guarantees, but if it's limited access, with good reason, and with a plan of action to do something better after Gotham, the add-on guys might allow it.

As for a patch, it might be good to make a post in one of the dev sub-forums and also see who you might be able to poke from this list: development advisors (wiki).

[Bstrdsmkr]

IIRC, the idea behind not allowing direct reads was to avoid add-on breakage. I want to say it was either montellese or memphiz's reasoning but my memory is fuzzy. Since there are a lot of long term changes planned for the db, any add-on not using a properly abstracted api would just get broken over and over

[Montellese]

I'm pretty sure I mentioned this once or twice. The database schema can change with any commit. XBMC comes with the necessary logic to upate the schema and its data but addons don't know about it. An abstracted API is a must (and would partly also be nice for xbmc's core itself, json-rpc etc).

[sphere]

I am wondering that no one mentioned that it actually already does work that XBMC stores and shows the partly- and watched-flag in plugin views.
Maybe you are not doing it correct in your python code?

You need stable (never changing) playable ListItem paths and you should use the setResolvedUrl-function.

See for example my 4Players Video add-on, play any video (to make it easier switch to list view, search a video with a min length of a few minutes), seek to about 50 percent, stop it. You will see the "partly watched flag". Exit the plugin or XBMC, enter the plugin again and the flag is still there. Same for the "already watched flag" (which means playcount > 1 which means at least one time seeked >90%).

Another approach (without the need for database read) would be tracking it in python and storing it via the add-on setting:
- use setResolvedUrl logic and when it gets called for playback use something like "addon.setSetting('movie-2342423-playcount', '1')" to store it
- when filling a list use "addon.getSetting('movie-2342423-playcount')" for each listitem to check and if its '1' set the playcount-property yourself

Regards,
sphere

[User 191275]

You need stable (never changing) playable ListItem paths and you should use the setResolvedUrl-function.

I already have stable URLs. I used setResolvedURL for a while (I'd use a plugin: URL and then resolve it to the http: URL once the user clicked on it). However, that caused strange deadlocks on XBMC 12.2, so I stopped doing that; it didn't seem to help me anyway, and I never had persistent watched/playing icons even with setResolvedURL.