[jacintech.fire]

Ok...
Wrote a script that calls a JSON Library update, I can specify directory and remote client...ran it on ALL clients Updating a different TV-Show episode or movie on each; and nothing...
"...8.7.3. Concurrent Inserts
The MyISAM storage engine supports concurrent inserts to reduce contention between readers and writers for a given table: If a MyISAM table has no holes in the data file (deleted rows in the middle), an INSERT statement can be executed to add rows to the end of the table at the same time that SELECT statements are reading rows from the table. If there are multiple INSERT statements, they are queued and performed in sequence, concurrently with the SELECT statements. The results of a concurrent INSERT may not be visible immediately..."
Any other ideas...

[Ned Scott]

Ok...
Wrote a script that calls a JSON Library update, I can specify directory and remote client...ran it on ALL clients and nothing...
Any other ideas...

Didn't you say you also use MySQL? If so, a library update would do nothing because those two databases (music and videos) wouldn't even be using the local SQLite files that are in XBMC/userdata/Database/

[Milhouse]

Really pointless argument, as always with you - the facts are you're doing something really stupid (also as always with you!) That you've been incredibly fortunate to avoid corruption doesn't alter anything - what you are doing is bound to cause corruption eventually, and it's probably no surprise you don't understand what you are doing.

[jacintech.fire]

Ok...
Wrote a script that calls a JSON Library update, I can specify directory and remote client...ran it on ALL clients and nothing...
Any other ideas...

Didn't you say you also use MySQL? If so, a library update would do nothing because those two databases (music and videos) wouldn't even be using the local SQLite files that are in XBMC/userdata/Database/

I think, the library update in JSON is akin to "Scan for New Content" on the sources menu...but I could be wrong...

[Milhouse]

Didn't you say you also use MySQL? If so, a library update would do nothing because those two databases (music and videos) wouldn't even be using the local SQLite files that are in XBMC/userdata/Database/

What he should try is deleting Textures13.db and browsing the library simultaneously on two or more clients. Of course it would help if he understood how his system actually worked.

[jacintech.fire]

Really pointless argument, as always with you - the facts are you're doing something really stupid (also as always with you!) That you've been incredibly fortunate to avoid corruption doesn't alter anything - what you are doing is bound to cause corruption eventually, and it's probably no surprise you don't understand what you are doing.

That could be true. If so, please help me: outline a set protocols I can follow to test your hypothesis...so far,mI have done as you ask and the results seem to validate my approach; but if I am wrong, I am willing to test your approach and see...

---

Didn't you say you also use MySQL? If so, a library update would do nothing because those two databases (music and videos) wouldn't even be using the local SQLite files that are in XBMC/userdata/Database/

What he should try is deleting Textures13.db and browsing the library simultaneously on two or more clients. Of course it would help if he understood how his system actually worked.

...please forgive my ignorance, but wasn't your argument that my setup, AS-IS, was inherently a nightmare waiting to happen. If so, why would I need to proactively precipitate anything...?
I already backup the content of the userdata folder to a third location, so even if I somehow "nuke" Textures{nn}.db, it would take a single command to restore...and again, 3.5 years on, it has not happened yet...

[Milhouse]

...please forgive my ignorance, but wasn't your argument that my setup, AS-IS, was inherently a nightmare waiting to happen. If so, why would I need to proactively precipitate anything...?

In order to confirm that your setup is prone to corruption (to you anyway, as it's clear to everyone else). This is the best approach - remove the SQLite databases and then re-populate simultaneously using two or more clients. You asked for "protocols I can follow to test your hypothesis" well, there it is.

Just because you have avoided corruption, by pure chance in the last 3.5 years by avoiding simultaneous SQLite database updates, doesn't mean you shouldn't confirm to yourself that your setup is fundamentally flawed and that at some point you will experience corruption.

[Ned Scott]

Ok...
Wrote a script that calls a JSON Library update, I can specify directory and remote client...ran it on ALL clients and nothing...
Any other ideas...

Didn't you say you also use MySQL? If so, a library update would do nothing because those two databases (music and videos) wouldn't even be using the local SQLite files that are in XBMC/userdata/Database/

I think, the library update in JSON is akin to "Scan for New Content" on the sources menu...but I could be wrong...

Yes, which has nothing to do with what we're talking about. You're asking why your MyVideos75.db file isn't corrupted when you've specifically configured XBMC to use a MySQL db, which means MyVideos75.db is. never. touched.

If you want to look for corruption then look in the remaining databases:

Addons
Epg
Textures
TV
ViewModes

If you don't use PVR then you don't use at least two of those, and the Textures DB is normally only updated once per day, which makes it hard (but certainly not impossible) to have an issue. Addons should only update when there are updates available for your add-ons, so again, no surprise that you haven't had an issue. ViewModes is more likely to contain an issue, but I don't really know how it works or how often XBMC writes to that database.

Even when there is corruption to those databases, it might not always be apparent. These aren't exactly critical functions for every single person. Maybe an add-on that was set as disabled gets re-enabled every so often, which is easy to miss. Every time you update XBMC you get a new copy of each of those databases, so you can't even be sure you've never had an issue in 3 and a half years.

Those are just the SQLite databases. XBMC generally doesn't behave when you have multiple clients reading and writing to the XML files, and many times the settings need to be specific to the hardware, especially when different displays are used with different resolution or refresh rates.

So much of this greatly depends on how a person uses XBMC. Just because you, in your tiny narrow world, do not have issues, does not mean that it is safe for other people to do without issue. Even if it's not a catastrophic issue, even if it only causes minor issues, those are not issues we want to deal with as support burden on xbmc.org. When we help people we generally assume they are not doing crazy things with their files. Different setups behave differently. Even different OSes have their own quirks and will handle differently, with or without an issue. The chances don't have to be high for an issue for us to discourage people from doing things that we know can cause an issue. It's happened before, it happens with other people all the time, so I don't really care if it doesn't happen for you.

You barely know what you are even talking about, so how am I supposed to even believe you in the first place?

[jacintech.fire]

...please forgive my ignorance, but wasn't your argument that my setup, AS-IS, was inherently a nightmare waiting to happen. If so, why would I need to proactively precipitate anything...?

In order to confirm that your setup is prone to corruption (to you anyway, as it's clear to everyone else). This is the best approach - remove the SQLite databases and then re-populate simultaneously using two or more clients. You asked for "protocols I can follow to test your hypothesis" well, there it is.

Just because you have avoided corruption, by pure chance in the last 3.5 years by avoiding simultaneous SQLite database updates, doesn't mean you shouldn't confirm to yourself that your setup is fundamentally flawed and that at some point you will experience corruption.

By that argument, the universe is flawed (at some point in the future, it will reach maximum entrophy and all wave/particle interactions will cease), should we call it day then?
It all comes down to statistic probabilities. In that sense, "at some point", I will open my front door and will be greeted by the event horizon of a back hole...

[Milhouse]

It all comes down to statistic probabilities. In that sense, "at some point", I will open my front door and will be greeted by the event horizon of a back hole...

We can only hope, though it likely will have trouble consuming such a large quantity of pigheaded ignorance.

[jacintech.fire]

Didn't you say you also use MySQL? If so, a library update would do nothing because those two databases (music and videos) wouldn't even be using the local SQLite files that are in XBMC/userdata/Database/

I think, the library update in JSON is akin to "Scan for New Content" on the sources menu...but I could be wrong...

Yes, which has nothing to do with what we're talking about. You're asking why your MyVideos75.db file isn't corrupted when you've specifically configured XBMC to use a MySQL db, which means MyVideos75.db is. never. touched.

If you want to look for corruption then look in the remaining databases:

Addons
Epg
Textures
TV
ViewModes

If you don't use PVR then you don't use at least two of those, and the Textures DB is normally only updated once per day, which makes it hard (but certainly not impossible) to have an issue. Addons should only update when there are updates available for your add-ons, so again, no surprise that you haven't had an issue. ViewModes is more likely to contain an issue, but I don't really know how it works or how often XBMC writes to that database.

Even when there is corruption to those databases, it might not always be apparent. These aren't exactly critical functions for every single person. Maybe an add-on that was set as disabled gets re-enabled every so often, which is easy to miss. Every time you update XBMC you get a new copy of each of those databases, so you can't even be sure you've never had an issue in 3 and a half years.

Those are just the SQLite databases. XBMC generally doesn't behave when you have multiple clients reading and writing to the XML files, and many times the settings need to be specific to the hardware, especially when different displays are used with different resolution or refresh rates.

So much of this greatly depends on how a person uses XBMC. Just because you, in your tiny narrow world, do not have issues, does not mean that it is safe for other people to do without issue. Even if it's not a catastrophic issue, even if it only causes minor issues, those are not issues we want to deal with as support burden on xbmc.org. When we help people we generally assume they are not doing crazy things with their files. Different setups behave differently. Even different OSes have their own quirks and will handle differently, with or without an issue. The chances don't have to be high for an issue for us to discourage people from doing things that we know can cause an issue. It's happened before, it happens with other people all the time, so I don't really care if it doesn't happen for you.

You barely know what you are even talking about, so how am I supposed to even believe you in the first place?

I was talking about corrupting my library; some of the supporting elements are in the userdata folder (i. e. xmfl, db files)...
Your argument is about compromising the whole setup by corrupting elements in the userdata folder...
...and your OWN argument contains exceptions...yet you continue that "my narrow little world setup" is a non-funtioning disaster; which could very well be true...except that for my needs, it has worked flawlessly for 3.5 years...and surprise, surprise has not experienced ONE of the incident and scenario you describe (which amount to taking the probervial sledgehammer to my setup just to see if it breaks)...

Throw all the insults you want, you got nothing...
...and like I said before, worse case, I restore from my daily backup...

If you are talking about something else...I can't help ya...

[Kib]

One of the symptoms of a broken addons.db : Your addons do not update automatically anymore, or retry 100 times against the mirrors before finally succeeding.
Hard to miss ? Yes.
Annoying for our infrastructure? Definitely.

[jacintech.fire]

One of the symptoms of a broken addons.db : Your addons do not update automatically anymore, or retry 100 times against the mirrors before finally succeeding.
Hard to miss ? Yes.
Annoying for our infrastructure? Definitely.

I don't use any add-ons...could this make that much of a difference?

---

It all comes down to statistic probabilities. In that sense, "at some point", I will open my front door and will be greeted by the event horizon of a back hole...

We can only hope, though it likely will have trouble consuming such a large quantity of pigheaded ignorance.

Let's try this:
--Five Displays sharing the userdata folder, one MYSQL database for synch
--Library updates are done via a webapp/script that targets specific displays and specific sources more than likely one at the time...

Device scenario that will cause a catastrophic failiure that cannot be recovered by restoring the userdata folder from existing backup (this is the litmus test)...
Rate such a disaster in a scale of 1 to 10 (1=minimal; 10=critical)

Please limit your response to creating the scenario. Save the insults for the after party...
Anybody...?

[Kib]

Of course you use addons. Scrapers, skins etc are all addons.
If you want to know which ones you use, check your addons folder in userdata and disregard the ones you do not have active at the moment.

You seem to miss the point that advocating to share your userdata to other people is not the same as doing it yourself. If people do not use mysql like you do they will have corrupted databases in no time. This has happened to enough people that we now advice people not to do it anymore in the wiki. We aren't "not supporting it", we are advising strongly against it because it has caused real issues for real people in the past.

Your setup just happens to avoid the largest issues sharing the complete userdata will cause. Still, it is a really bad idea for almost everyone to do this - especially if your clients are not on the same type of hardware.

[jacintech.fire]

Of course you use addons. Scrapers, skins etc are all addons.

I thought you meant, add-ons you add after the install (Skins, youtube, nexflix, ***films, etc). I use the default skin (confluence) and the TVDB, IMDB, TMDB (which come preloaded) and that's about it...