[tjs4ever]

Clarification Needed – Kodi Database on MySQL

Hi all,
I’ve been using the software more and more throughout the house, and now that I have three Kodi-dedicated PCs (all Win7 in domain environment) using the same media source, it made sense to centralize the database. I made a tiny VM on my ESXI host to run Ubuntu and mysql, followed the guide and easily created an advancedsettings.xml that I have copied to each computer. It is convenient to no longer have to update the library on every machine (though my “main” PC still scans at app launch). My question regards scraping:

On the main PC, my sources (SAMBA shares – mapped under a common drive letter) appear in Video>Files as expected, but the sources are set to “off” and scrapping set to “exclude”. Yet everything scans and updates at application launch as expected. If I set the sources and disable the exclusions, I end up with duplicates for every media file. I am a bit confused by this behavior – do I not have any control over the scraping, or is it now fully automatic?

I exported the local database to a single file before switching to MySQL and imported after creating/using the advacedsettings.xml (as per the guide on the wiki). I did ignore the guide’s recommendation and continue to use drive letters for the SAMBA shares – Kodi will be the least of my troubles if I lose the mapping to these drives anyway as my setup is somewhat complex.

I am hoping someone could shed light on why the duplicate files occur, and if I should start over with a “clean” Kodi install and rebuild/reimport.

[helta]

Do not use drive letters. Period.

You have to use smb:// paths for all your shares.

[Starscream]

Using drive letters is a bad idea if you like to integrate non-windows hardware.
Are you sure to use the same drive letters and paths on all devices?
Settings on all machines the same?

I just scrape on 1 machine and use smb protocol.
So all my devices (windows, linux, android, ftv) work very well.

[helta]

Think of it this way, if you scrape the Z:\ from Client A into the mySQL database the paths would be like:
Z:\Movies\Batman\Batman.avi

Now Client B tries to watch Batman.....it can't find it because its on Client A's Z:\ drive.

[Starscream]

If client b also have a z drive there should no problem (cant test it because of a missing 2nd win machine).
But i realy dislike the idea of having letter for ressources.
This is some kind of 70s technology.

[helta]

Starscream: No. Why would Client A's movie source as be the exact same as Client B's. That's redundant. I think you are missing the point.

Here is the WRONG scenario that is scanned into the mySQL library:
Client A has a source Z:\Movies
within that folder he has a movie Z:\Movies\Batman\Batman.avi. It gets scanned into the mySQL library with that exact path.
Client B boots up and tries to access Batman. It cannot find it because Z;\Movies\Batman\Batman.avi does not exist on Client B's machine.

Here is RIGHT scenario:
Client A shares his Z:\Movies folder via samba share, nicknamed "192.168.2.1/Movies", it gets scanned as "smb://192.168.2.1/Movies/. ClientB then can access Batman.avi because its pointing to a network source.

Do you get it now?

[Starscream]

I already got it before.
But as long as client b also has the same location mapped as z there shouldnt be a problem.

But in general: do not use drive letters

[tjs4ever]

I think you are all missing the point:

This is in a DOMAIN environment. There is a Domain Controller, a DNS and WINS server, there are two file servers, I have RAS, NPS, DFS Namespaces and RADIUS (802.11x) running. Next month I am adding an email server and will eventually experiment with DFS Replication. When a user logs in his/her drives are mapped as per login script. Applicable users get an "M" (Media) drive mapped at login, along with an individual home folder, group policy, etc. User A's "M" drive is certainly the same as User B's "M" drive. Please trust me when I say Kodi will be the least of my worries if my domain goes down.

helta: You seem confused that ClientA and ClientB can have the same movie source: imagine a mid-sized or larger business with 30+ employees in the Finance Department. Is it possible that each employee can have a unique drive letter for their "F" (Finance) folder? Two or more computers can certainly share a common "Z" drive, even without complicated server setups. You can test this easily in Windows by sharing any folder on PC1 and mapping the folder on PC2, PC3, etc. I am not aware of any upper limit - thousands of users can have the same "F" drive mapped from one location simultaneously.

I would never map my folders, or point Kodi to an IP address: this would circumvent the redundancy/performance/reliability gained by having multiple servers share the load. I understand the benefit of using an IP or UNC for 99% of circumstances, this is not applicable in my situation. Period. I suppose I could use DFS Namespace as a UNC path, but \\tj.com\Share\Media is the path used in my login script - if "M" fails this means \\tj.com is down as well...

Starscream: No, I don't think any drive letters until the 80s

I have integrated non-windows hardware (to my media at least) by running MiniDLNA on a small Linux box, otherwise we have good 'ole SAMBA and FTP. I appreciate all of the prompt responses - but really my question is just about the scraping. I don't understand Post#3:

"Are you sure to use the same drive letters and paths on all devices?
Settings on all machines the same?"

Have I indicated anywhere that I am unable to play or access my media?

Scraping: The "Set Content" screen has "This Directory Contains :<NONE>" and "Exclude selected folder from scans" enabled - yet everything scans and updates at application launch on "Main" PC as expected (Kodi was set to update library at launch when using a local database. I left that setting the same when I switched to MySQL). If I set the sources and disable the exclusions, I end up with duplicates for every media file. I am a bit confused by this behavior – do I not have any control over the scraping, or is it now fully automatic? Can someone with a centralized SQL-based library tell me what their scrape settings are? Should I export my library and start again on a clean Kodi installation, or is this the expected behavior?

[Ned Scott]

Last I hear, when Kodi uses MySQL it will get confused by the backslash. It needs an address that uses forward slashes, unless something has changed, but I honestly don't know. If you need to, Kodi will handle DFS just fine if you add it as an "smb://tj.com/Share/Media/" path.

As for the duplicates, it sounds like you imported the database and then manually added a file source with content set, and somewhere in there the two paths are not exactly the same. Adding a source more than once shouldn't normally cause duplicates unless there's something different in the path. Kodi is very picky about this and it's even case sensitive. It might even be the forward/backslash issue that is causing the duplicates.

Setting a source to be excluded might not correct this if, again, the path is different at all. Kodi is slightly disconnected in the paths it shows you in the GUI and the paths it actually uses for library updates, which is something that should improve in the future. How it works now is that there is a path in the GUI (stored in sources.xml) and there is a path for library content in the actual library database (which is now in the MySQL DB).

If you delete the database and start fresh under MySQL, without importing anything, does it work and not give duplicates?

[tjs4ever]

After experimenting with this for a while, it seems the media paths are "stuck" after importing from backup. Even when I removed myadvancedsettings.xml in order to switch back to my local database, I end up with duplicates. I have tried using a local database and changing the media path from "M:\" to smb://tj.com/Share/Media and for about 80% of files this was OK - the other 20% or so produced duplicate files.

The only thing I really care about is watched status. It seems that all of my library backups are useless as they all produce this problem. Perhaps the import would have been fine from day 1 had I not used a drive letter - but there seems no way to gracefully switch from using a drive letter to using a UNC path, and I have not found a way to import my library and also set Media paths without creating duplicates.

I am recreating the database on MySQL from scratch - I only need the scrapping to work on the Main PC: I don't care if other PCs can't have paths and media types set. It is a shame to have lost my watched status for everything - my database is quite large. I am not sure if I am brave enough to try exporting/reimporting once everything is setup again, though I do suspect the behavior might return if I were to try.

[tjs4ever]

I think I may have discovered a bug:

Whenever I restore my library from backup (single file) the sources are not set as part of the restore (at least in the GUI). Re-adding the sources is what causes issues and causes duplicates, loss of watched status, etc...

Can anyone confirm?

[Ned Scott]

That's not a bug. That's exactly what I described before, where the sources in the DB are a separate entity than the sources in the GUI. Adding them again in the GUI will only cause an issue if the path is different in any way.

[Starscream]

You could inspect the path table inside the database to check for duplicates.
It looks like that the information inside the backup is not the same as on a newly added sources.

As Ned said: / or \ could also be a problem like a or A.
m:/test is not the same as M:\Test

But as i wrote befor: i have a bunch of devices with different OS and unfortunately i am not able to reproduce this behaviour because ther is just 1, which natively supports drive letters.

btw: afaik drive letters were introduced with CP/M (1974). So it realy is technology from the 70s and shouldnt be used today

[trogggy]

The only thing I really care about is watched status.

That's easily solved.
Back your watched status up to an xml with script.watchedstates.. Delete library (after making a backup just in case), re-scan, import watched-state backup. Done.

Note that you need to make changes to the script before using on gotham / helix. That takes 2 minutes, detailed here.
I use this to backup watched states every now and then and before a re-scan. There are probably other ways, but I know this one works.

[Vaiojuan]

Starscream: No. Why would Client A's movie source as be the exact same as Client B's. That's redundant. I think you are missing the point.

Here is the WRONG scenario that is scanned into the mySQL library:
Client A has a source Z:\Movies
within that folder he has a movie Z:\Movies\Batman\Batman.avi. It gets scanned into the mySQL library with that exact path.
Client B boots up and tries to access Batman. It cannot find it because Z;\Movies\Batman\Batman.avi does not exist on Client B's machine.

Here is RIGHT scenario:
Client A shares his Z:\Movies folder via samba share, nicknamed "192.168.2.1/Movies", it gets scanned as "smb://192.168.2.1/Movies/. ClientB then can access Batman.avi because its pointing to a network source.

Do you get it now?

Good afternoon,
I understand what you mean because I'm trying to share the MySQL on an external hard drive data in a HTPC and PC2 does not recognize the movie and I think it's because the drive letters.
I am using the G Translator and I fail to understand the whole post, my English is limited, I speak Spanish.
How do I have to proceed to assign names instead of letters? properties directly on the hard drive?