Login at Kodi Home

Mihara · 2012-09-20, 17:27

I have XBMC 11.0 Eden, running on Linux and Windows sharing a MySQL library.

I want to have certain titles in my library only be visible if a password is entered, but everything else be accessible for viewing with no requirement to enter a password. Using instructions from http://wiki.xbmc.org/index.php?title=Med...es#Locking I have done the following:

Moved all restricted titles into a separate SMB share with it's own access restrictions.
Added it into XBMC as a video source.
Enabled master lock, as per http://wiki.xbmc.org/index.php?title=Set...aster_lock -- I did not check the 'ask for master lock code on startup' nor any of the master lock checkboxes.
Set password on the abovementioned video source as described in the wiki.

At this point everything works as expected and as I want it to work -- the video source has a lock icon next to it, no titles from it are visible in the library until I select it directly and enter the password, titles in it survive library cleanup when it is not unlocked, and when I relock it, the titles vanish from the library again. No other functions are restricted, which is just how I like it. (It's not meant to be secure in the first place, just to protect these titles from being seen without explicit instructions.)

However, the moment I restart XBMC - either the Windows or the Linux installation - I find that the source is freely accessible, and Master Lock code is completely disabled. Checking specific checkboxes in the master lock window produces no change in this behaviour. Enabling it again makes the restricted source locked again, but only until the next restart. I have previously not done anything regarding user profiles except setting up advancedsettings.xml to share certain configuration files as recommended in the wiki, by the way, so if any profile is supposed to be the default, I'm using it.

What am I doing wrong and how do I get the lock to stick?

artrafael · 2012-09-20, 18:27

I'm not seeing that problem.

Check your sources.xml file in your userdata (wiki) directory after relocking that source (windowize/minimize XBMC so you can access your OS's file manager). Make a note of the <lockmode>, <lockcode> and <badpwcount> entries for your restricted source. Exit and restart XBMC. Check those settings in sources.xml again. Are they the same as before? Specifically, is the setting for <lockmode> a number greater than 0?

Mihara · 2012-09-20, 19:07

(2012-09-20, 18:27)artrafael Wrote: Check your sources.xml file in your userdata (wiki) directory after relocking that source (windowize/minimize XBMC so you can access your OS's file manager). Make a note of the <lockmode>, <lockcode> and <badpwcount> entries for your restricted source. Exit and restart XBMC. Check those settings in sources.xml again. Are they the same as before? Specifically, is the setting for <lockmode> a number greater than 0?

Code:
<source>

            <name>Restricted Video</name>

            <path pathversion="1">smb://JOHNHARRY/restricted/Video/</path>

            <lockmode>3</lockmode>

            <lockcode>92d472e97323cd3597f4506c62182091</lockcode>

            <badpwdcount>0</badpwdcount>

        </source>

Yep. sources.xml is perfectly fine and remains so upon exiting and restart. (And it's actually shared between the two installations through path substitution and located on an SMB share.) What disappears is the master lock itself, not the individual source lock. As long as master lock is 'disabled', source locks are not active. Master lock becomes disabled upon restart. As soon as I re-enable it by setting a new master lock password, source lock becomes active again.

Mihara · 2012-09-20, 22:46

Well, looks like I found it:

Code:
<advancedsettings>

<pathsubstitution>

    .......

    <substitute>

    <from>special://masterprofile/profiles.xml</from>

    <to>smb://JOHNHARRY/xbmc/userdata/profiles.xml</to>

  </substitute>

</pathsubstitution>

Apparently you aren't allowed to do that sort of thing, although I don't see why not. Once I remove that particular substitution, master lock code sticks.

~~Ned Scott~~ · (This post was last modified: 2012-09-21, 00:14 by Ned Scott.)

My guess is that since multiple XBMC installs are sharing that file, one install sets the lock and another install must be then setting an unlock. If you need the profiles.xml file to be shared then you might try this: close all XBMC installs, open just one, set everything up, then open the others. That way they all start out on the "same page" and aren't conflicting. Then again, it's probably just easier to manually copy the profiles.xml file over to each client and consider profiles.xml to be something that isn't "safe" to share.

I also see that it's not listed in the XBMC Wiki for "syncing other parts of XBMC" so it's likely this has come up before, or something similar.

Mihara · 2012-09-21, 07:02

(2012-09-21, 00:12)Ned Scott Wrote: My guess is that since multiple XBMC installs are sharing that file, one install sets the lock and another install must be then setting an unlock.

This is quite definitely not the case, only one installation was running and restarting while I was messing with the master lock. After establishing it's not working, I went on to try the other installation. In fact, XBMC apparently only writes this file on shutdown, but not while it's running.

(2012-09-21, 00:12)Ned Scott Wrote: I also see that it's not listed in the XBMC Wiki for "syncing other parts of XBMC" so it's likely this has come up before, or something similar.

It looks to me like an obscure bug, actually. It's like the decision to create a fresh profiles.xml because it is missing is made before path substitutions are processed, but the actual creation happens after, so an existing profiles.xml is overwritten.

~~Ned Scott~~ · 2012-09-21, 10:20

It's only a bug if it doesn't work with just the one instance of XBMC. None of XBMC's settings were made to be used with path subsituition. The fact that any of it works (including thumbnails) with path subs is just a bonus.

Mihara · 2012-09-21, 13:10

(2012-09-21, 10:20)Ned Scott Wrote: It's only a bug if it doesn't work with just the one instance of XBMC. None of XBMC's settings were made to be used with path subsituition. The fact that any of it works (including thumbnails) with path subs is just a bonus.

Just one instance of XBMC which has such a path substitution for non-database-sharing reasons (I can imagine a few) will exhibit the exact same inability to keep a master lock. Smile

kyoo · 2014-09-10, 05:12

I have run into this same issue.. with xbmc 13.2, still.. *sigh*.. Has anyone found a fix for a centralized masterlock config?

~~Ned Scott~~ · 2014-09-10, 06:12

(2014-09-10, 05:12)kyoo Wrote: I have run into this same issue.. with xbmc 13.2, still.. *sigh*.. Has anyone found a fix for a centralized masterlock config?

*sigh* it's not a bug. Do not use pathsubs with profiles.xml, period. Maybe in the future we'll have some better form of centralized management, one that doesn't require such hacks. Until then, it's not even a feature in XBMC/Kodi.

kyoo · 2014-09-10, 20:30

Ned, Thanks for chiming in.. I'd love to see that feature in a future Kodi release... Perhaps just toss it into the mysql database integration.. Thanks!