Weird database and profile question
#1
Question 
Can anyone think of a way that the "viewed" or "playing position" could be shared across two profiles? Now here is the weird part, each profile has different source IPs but the content of each of the servers they point to are synced together (the same).

So to explain:
1st profile sources point to a server share named "Media" on 192.168.0.100
2nd profile sources point to a server share named "media$" on 192.168.0.200

Both server shares are identical, (one is a full backup of the other).
The reason for the database issue is that sometimes the Primary server is removed, and media is temporarily watched from the Backup, but when the Primary comes back, the watched statuses are different between the two profiles.

I could see how keeping the Backup offline and having it's IP clone the Primary so that when the Primary goes away the profile is still pointing to the same source, but that causes issues when trying to keep them synced together easily and the sharename would need to match.

I could see it working if the "path substitution" path was held in the library, then I could simply create an SQL database and point each profile to it with each profile having a different "advanced.xml" in which each is having the substitution point to a different server, it just doesn't seem that the library is holding the "replacement" name but the whole real path (and that won't work for what I want).

So that the primary profile's advanced.xml was configured as:

<pathsubstitution>
<source>smb:\\192.168.0.100\Media</source>
<target>\THESERVER\</target>
</pathsubstitution>

and the secondary profile's advanced.xml was configured as:

<pathsubstitution>
<source>smb:\\192.168.0.200\media$</source>
<target>\THESERVER\</target>
</pathsubstitution>

If the library held "\THESERVER" as the beginning of the path for each object in the library, this would work, but I think the library is resolving it to the real path.

Is this the case, and if so, is the plan to keep the library always pointing to the real path? It seems like having it store the apparent path would provide more flexibility to the user. eg. If we chose to use a substitution, it would allow us to move the library to different sources and IPs without needing to rebuild from scratch every time.
Using a NUC7PJYHN and a 2820FYKH0 Intel NUC running LibreELEC, and two FireTVs.:)
Reply

Logout Mark Read Team Forum Stats Members Help
Weird database and profile question0