[xexe]

I come back to my original point. How do you handle multiple users when extracting or using nfo for play count

[billyad2000]

I have just heard about this thread and I thought I would throw in my thoughts,

@jmarshall
The only case that one can make an argument for is if no playcount exists (or, similarly, if db playcount < nfo playcount).
That seems workable, the problem is that when people first start using XBMC they may have a library of 1000+ movies, most of which they have watched. The issue of multiple users is not solved though.
Have you actually had complaints about .nfo files containing the playcount.
It does look like the only people that have posted against nfo files holding the playcount status don't actually use .nfo files.

I know it is difficult to please everyone, but why not have an option within XBMC, import playcount or not.

[xexe]

My point is that to be compliant with how XBMC works the nfo would have to have a way of storing playcount per user. Otherwise my wife could import my play count or vice versa.

These XML nfo creators have their place but they essentially dump scrape data beside your video content to save on future internet bandwidth/increase speed/better match how certain users work. However watched status is not the same as scrape data, you dont for instance scrape if you have watched an episode of House from TVDB (although its perfectly possible you may in the future)

[smcnally75]

I come back to my original point. How do you handle multiple users when extracting or using nfo for play count

What percentage of XBMC users do you think actually have separate databases and user preferences setup like you do? I'd be willing to bet that less than 10% of the users out there have it setup that way. I also understand your concern about trying to do everything in XBMC, but it is also just more convenient to do some things elsewhere. For instance, you can't rip your movies from within XBMC, can you?

[xexe]

No need to get snarky simply come up with a method that handles multiple users with this nfo technique ratehr than obsessing over something completely unrelated.

[RockDawg]

No need to get snarky simply come up with a method that handles multiple users with this nfo technique ratehr than obsessing over something completely unrelated.

How does XBMC currently handle the watched status for multiple users? What happens when you watch a movie all the way through and XBMC automatically marks it as watched, but other users haven't seen it yet? How is that currently handles?

This discussion is all about how XBMC handles nfo files, which you obviously don't use. For your situation, why does it matter how it handles them? You're not using them so nothing will overwrite the db. XBMC should act for you as if it didn't even support .nfo files. Again, I don't see what your beef is.

[spiff]

you have several ways of operating with separate profiles.

you can share the db, in that case you have a common watched status.
or each profile can have a separate db. then everything is separate. BUT, as xexe points out, if we import watched status from the .nfo's, all profiles will import it.

[RockDawg]

Refreshing movie information should not alter the play count - they're two separate things: Metadata for the movie which could come from anywhere, and play count information which is specific to the user. These must be kept separate (thus the reason for moving the playcount info into the files table).

The only case that one can make an argument for is if no playcount exists (or, similarly, if db playcount < nfo playcount).

Cheers,
Jonathan

I see what you're saying, and you're right, refreshing should not alter the play count. I wonder, is there any difference code-wise between scanning and refreshing? If there is, maybe you could have scanning read the play count from the nfo file, but not refresh? The logic there would be that scanning would be the first time a movie is put into the db and it may likely have been previously watched, but a refresh would be for movies already in the db and should already have a correct watched status. Just a thought.

[xexe]

that seems sensible until you consider that if two people have access to the same files they will not both be able to refresh the status using that method.

It is simply a matter of solving that problem and you then have multiuser capabilities.

[RockDawg]

you have several ways of operating with separate profiles.

you can share the db, in that case you have a common watched status.
or each profile can have a separate db. then everything is separate. BUT, as xexe points out, if we import watched status from the .nfo's, all profiles will import it.

I see. Thanks for the explanation.

I would think that the simple solution then for multi users would be to leave the <playcount> tag empty on their nfo files. That has the same end result as the current method of not even reading the play count from nfo's. Except now nobody can use the play count from the nfo even if they want to.

[spiff]

yeah, i think adding it back optionally makes sense. but that means logic in stuff like mc to not store the tag unless the user explicitly asks for it. and i think an xbmc export should never store it

[watzen]

yeah, i think adding it back optionally makes sense. but that means logic in stuff like mc to not store the tag unless the user explicitly asks for it. and i think an xbmc export should never store it

what about those who use the export feature as a database backup(for when you have to rescan the library)? It would be good to not have to go through the whole library to set the correct watch-status again. Perhaps a extra dialog (after the per file/one big xml dialog) that asks: "export playcount?".

[sho]

What's wrong with a real backup?

[ashlar]

What's wrong with a real backup?

The single file backup option doesn't back up thumbs, posters, fanart, etc.

[spiff]

copy does. just fine.