Reply to thread

Message: <blockquote data-quote="Guzzi" data-source="post: 1111498" data-attributes="member: 55213">So it is a three part movie and you want all of them in a single movie entry?<ul> <li data-xf-list-type="ul"> Depending on the settings, you should be able to select if to e.g. delete only DB record entry - if it is not working it might be a bug - or caused by the issue you described later (DB update 'not accepted') - logs might help to understand what's happening. Might be same reason why 1st option "not working" - see explanation below.</li> </ul>It seems that this was happening.Central setup in general works as follows:- Each client when started loads the central DB content into a local cache that serves as data source during runtime.- Each client monitors changes of the central DB - whenever there is a change, the client re-loads the central DB to make sure the cached content is "current"- On "resume after standby", a reload is initiated to make sure changes on the DB while the client was sleeping will update the cached content ont he client- When a client makes changes on the cache content (e.g. a movie set to "seen", local updates to a movie (grabbing), imports, trakt related sync, etc. the client writes those changes back to the server. The client "locks" the central DB for this time to make sure, not two client write-back at the same time.- When two clients want to write back at the same time, the one who first attempts to create the lock will write-back - the other would detect the update and first update local cache, then write back- Each client only waits for a certain time to write-back - if that timer times out, the change will not be written back to DB - changes might get lost, e.g. when a cache cointent refresh then will be done by update by other client from cemntral DB. This is needed to avoid infinite waiting in lock situations - it is "not perfect" per definition - but usually does not happen too often in reality.As you describe, changes you do from one place (e.g. one MF-client - or a workstation where you manage your DB) get lost, when you shutdown a client - that seems to be an indication, that the clients do not update their cache content when you change the (central) DB - and thus might later overwrite central DB with their last status, as the client thinks that is up to date with central DB.So I would check the logs of the clients shortly after you made a change to the central DB - you should see something like:[code]2014-11-22 14:04:40,621  Info [ 10 |       MyFilms ]: WatcherChanged() - New FSwatcher Event: Changed: '\\server\share\db.xml'2014-11-22 14:04:47,955 Debug [ 69 |  BaseMesFilms ]: LoadMyFilmsFromDisk() - Current Readlocks: '0'2014-11-22 14:04:47,965 Debug [ 69 |  BaseMesFilms ]: LoadMyFilmsFromDisk() - opening '\\server\share\db.xml' as FileStream with FileMode.Open, FileAccess.Read, FileShare.ReadWrite2014-11-22 14:05:02,772 Debug [ 69 |  BaseMesFilms ]: LoadMyFilmsFromDisk() - closing  '\\server\share\db.xml' FileStream2014-11-22 14:05:02,772 Debug [ 69 |  BaseMesFilms ]: LoadMyFilmsFromDisk() - Finished  (1488 ms)2014-11-22 14:05:02,772 Debug [ 69 |  BaseMesFilms ]: CreateOrUpdateCatalogProperties() - add Properties done ... (0 ms)2014-11-22 14:05:02,772 Debug [ 69 |  BaseMesFilms ]: CreateOrUpdateCatalogProperties() - Adding CustomFields Definitions done ... (0 ms)2014-11-22 14:05:04,257 Debug [ 69 |  BaseMesFilms ]: LoadMyFilmsFromDisk() - Calc PreAcceptChanges ... (148 ms)2014-11-22 14:05:04,685 Debug [ 69 |  BaseMesFilms ]: LoadMyFilmsFromDisk() - Calc & CustomField Copy Finished ... (190 ms)2014-11-22 14:05:04,685 Debug [ 69 |  BaseMesFilms ]: LoadMyFilms() - Finished ... (success = 'True') (1673 ms)[/code]You could easily test this by simply saving the central DB file from an editor.After a resume you should see somthing like:[code]2014-11-22 11:48:56,139 Debug [  1 |       MyFilms ]: MyFilms received power event Resume2014-11-22 11:48:56,139  Info [  1 |       MyFilms ]: PowerModeChanged() - MyFilms is resuming from standby2014-11-22 11:48:56,412 Debug [  1 |       MyFilms ]: PowerModeChanged() - Network not yet ready or DB file not accessible on try '1 of 10' to reload - waiting for next retry2014-11-22 11:48:56,966 Debug [  6 |       MyFilms ]: WatcherError() - A FileSystemWatcher error has occurred: Der angegebene Netzwerkname ist nicht mehr verf³gbar2014-11-22 11:48:58,432 Debug [  1 |       MyFilms ]: PowerModeChanged() - Network not yet ready or DB file not accessible on try '2 of 10' to reload - waiting for next retry2014-11-22 11:48:59,877 Debug [ 27 |       MyFilms ]: MyFilms is connected to the network2014-11-22 11:49:00,484 Debug [  1 |       MyFilms ]: PowerModeChanged() - MyFilms is reloading movie data to memory cache.2014-11-22 11:49:00,499 Debug [  1 |  BaseMesFilms ]: LoadMyFilmsFromDisk() - Current Readlocks: '0'2014-11-22 11:49:00,521 Debug [  1 |  BaseMesFilms ]: LoadMyFilmsFromDisk() - opening '\\server\share\db.xml' as FileStream with FileMode.Open, FileAccess.Read, FileShare.ReadWrite2014-11-22 11:49:02,235  Info [  6 |       MyFilms ]: InitFSwatcher() - FSwatcher started watching - DB-file: '\\server\share\db.xml'2014-11-22 11:49:02,235 Debug [  6 |       MyFilms ]: WatcherError() - FSwatcher restarted after error !2014-11-22 11:49:19,181 Debug [  1 |  BaseMesFilms ]: LoadMyFilmsFromDisk() - closing  '\\server\share\db.xml' FileStream2014-11-22 11:49:19,181 Debug [  1 |  BaseMesFilms ]: LoadMyFilmsFromDisk() - Finished  (1882 ms)[/code]If you're missing those refreshes, the above described problem might occur - again, log should tell us more...</blockquote>

Verification