[agb2]

I have noticed that profile-specific favourites do not work in Kodi v18.
I am using the Milhouse LE test builds.
For the moment, I cannot test with OSMC v18 test builds due to other profile-related issues.

All profiles share the 'favourites.xml' file in userdata instead of using the file in userdata/profiles/<profile>.
It does not appear to be skin-related. I created a test profile, using all defaults and it sees the favourites created by other profiles.

This does not occur on v17.
It appears to be a Kodi core issue rather than LE/OSMC specific, although as stated above I have not verified on OSMC v18.

Is anyone else seeing this?
Any ideas?

[trogggy]

Yep, and I've been meaning to do a bug report. It's a kodi issue, not specific to the pi or libreelec. There have been a ton of changes in favourite for Leia.
I'll quote myself:

As of a couple of weeks ago there were some fairly major changes in the way favourites are handled in Leia.
https://github.com/xbmc/xbmc/pull/11967
The idea is that favourites are kept in memory rather than being reloaded from favourites.xml each time they're needed.
That sounds great, more efficient, probably has a ton of advantages that I can't think of. There are times, though, when it would be useful to be able to reload the favourites from favourites.xml. At the moment the only way I can see to do that is by restarting kodi (or presumably changing profiles).

A way to reload favourites - which would be triggered on profile switch or manually via a built-in function - would solve that, but obviously I have no idea whether that's trivial or a major pain for devs.

[agb2]

Hmmm, thanks for the info.
It seems to me that the issue is that Favourites are loaded from the wrong place in the first place, i.e. userdata.
This is the 'profile' directory if you have no profiles or if you autologin to Master.
But I would certainly expect Favourites to be reloaded [and from the correct place!] on profile switch.

[agb2]

As an experiment, I knocked up a dummy service addon and installed it.
It starts when Kodi starts and does nothing except log all Notifications, using xbmc.Monitor.
I was expecting to see something when profile switching, but nothing at all got logged.
At the back of my mind was the thought that I could use this as a trigger to switch favourites.xml, depending on profile.
Clearly that won't work.

[trogggy]

As an experiment, I knocked up a dummy service addon and installed it.
It starts when Kodi starts and does nothing except log all Notifications, using xbmc.Monitor.
I was expecting to see something when profile switching, but nothing at all got logged.
At the back of my mind was the thought that I could use this as a trigger to switch favourites.xml, depending on profile.
Clearly that won't work.

There isn't any way to switch favourites at present as far as I can see.

[agb2]

What I had in mind was a hack :-}
Since I don't actually use the Master profile, except as a sort of 'admin' user, it has no media etc.
So the favourites.xml in userdata is empty.
I have manually copied the favourites from a profile which *has* got media, favourites etc. to userdata.
The hack would be to automatically copy profile/favourites.xml to userdata when a profile logs in.
I could tweak the dummy service I mentioned above to do this, but it will need to start on login, not when Kodi starts.

I suppose I would need to copy the xml back to the profile directory on logout as well.

[trogggy]

Your hack won't work because as far as I can see favourites are only read from favourites.xml on startup. Hence my feature request.

[agb2]

Ah. I hadn't fully grasped what your feature request was getting at :-}
You're right, the hack won't work.
I've confirmed that manually overwriting userdata/favourite.xml has no effect until Kodi is restarted.
Bah!

[agb2]

I've added my tuppence-worth to your request.

[trogggy]

I've added my tuppence-worth to your request.

Cheers. Maybe I should try to make the request a bit clearer. Anyway I've filed a bug report:
https://trac.kodi.tv/ticket/17478#ticket

[agb2]

I'll keep an eye on that, thanks :-}

[agb2]

I've just had a look at the pull you referenced.
This line is clearly the problem:
std:tring favourites = "special://xbmc/system/favourites.xml";
This new new favourites service is *completely unaware* of profiles!
I will add a comment to the trac ticket when I manage to log in.

[trogggy]

I've just had a look at the pull you referenced.
This line is clearly the problem:
std:tring favourites = "special://xbmc/system/favourites.xml";
This new new favourites service is *completely unaware* of profiles!
I will add a comment to the trac ticket when I manage to log in.

Favourites are definitely being loaded from 'special://profile' - you can test that by sticking a favourites.xml inside a test profile (userdata/profile) and starting up in it - rather than from 'special://masterprofile' (userdata).
As for the reference to "special://xbmc/system/favourites.xml" - that's not looking at the data folder at all. On windows that would be programfiles\kodi\system\fav...stick a favourites.xml in there and it will load, but it doesn't normally exist.

[agb2]

Hmm. That's not the behaviour I see.
But the difference may well be that I autologon to Master, which I use as a sort of 'admin' account only.
You're right about the special:// business - got over-excited when I saw that :-}

I will try setting autologon to a different profile, just to confirm what you said.
Cheers.

<edit>
Yup, confirmed.

[trogggy]

If you log on to the Masterprofile then special://profile and special://masterprofile are the same place. So yes, you'll always load favs from userdata that way. If you set autologin to 'last profile' it's easy to see.