INTERACT FORUM
More => Old Versions => Media Center 14 (Development Ended) => Topic started by: ADDiCT on March 06, 2010, 12:59:13 am
-
Heads up: just noticed that 14.0.151 had cleared the "Filename" field for all files, which essentially boils down to a "broken" library with no chance of recovery (bar entering all filenames by hand). I was able to restore the library from an older backup, but still MC shouldn't do this.
The question is of course: why did this happen? The only reason i can imagine is that my library is located on a file server and it is possible that i have rebooted the server while MC was running on my "media player" machine (Windows update etc.). IIRC quite some time ago some fixes were implemented to allow MC to handle that kind of situation gracefully though. MC _should_ handle network dropouts gracefully in any case. Just imagine having your library stored on a server and connecting to it via WLAN, which is prone to disconnects. This is just one of many possible problematic scenarios.
Am i remembering correctly that MC had those fixes i spoke of implemented? Should MC handle "disappearing" library files gracefully or do i have to be extra-careful in the future?
-
If the plug is pulled while MC's library files are being updated, you will lose data. Best to close all programs, then reboot.
-
I can't rule out that MC writing to the library and a reboot/network disconnect happened at the exact same time, but i think that's highly unlikely. MC has been idling most of the time on the "client" machine, not playing anything. To avoid future incidents it'd be most interesting to have answers to the questions i've asked at the end of my original post.
-
I think what you're asking for is more of an OS question. There is something called a journaling file system that allows an OS to reconstruct the writes in cases where an interruption occured.
I don't believe what you saw was an MC problem.
-
I beg to differ. There is no such thing as JFS over a network connection (though it would be a nice feature). As i've said: my library is located on a file server, and the client is accessing it via a mapped drive letter. My problem is definitely a MC problem because it's MC's library that has been affected ;). May i ask again for answers to the questions in the first post please?
-
Was MC making any tagging updates at the time this happened ?
Specifically tags that get written to the files themselves when the interruption occured.
-
Nope. As i've already written, MC was just "idling" on the client. No playback or tagging activity going on. That's exactly the reason why i'd like to know whether MC handles "disappearing" library data gracefully or not.
-
I agree with JimH I'm afraid.
Rebooting the server whilst files are being accessed/ modified from a remote client is always going to end in tears someday.
First question is which OS are you running on the server?
Second would be whether it was a 'hard' reboot or a 'soft' reboot? (In simple terns, did you press flick the switch or use the OS to restart?)
If it was a hard reboot, I'd say it's almost certain that your operating system is running delayed writes, and one of these got caught in the reboot.
Otherwise I'd hazard a guess that something was running in the background, either a tag update, an auto-import job, or simply MC playing something.
All of these are going to be writing to the DB, and unfortunately killing the network drive at the wrong time can easily cause corruption, with *nothing* that MC can do about it.
-Leezer-
-
What i was trying to explain is the following: my "playback" machine is running 24/7 with MC open. At times the machine will sit like this for several days, doing nothing at all. During an interval like that it's _possible_ (not certain, but _possible_) that i've rebooted the file server with the library files on it. During that server reboot there was zero (user initiated) MC activity. None. When i looked at the client machine again, all "Filename" fields were empty all of a sudden. The rest of the library was intact - i could search for tags, browse via view schemes, etc. .
-
What i was trying to explain is the following: my "playback" machine is running 24/7 with MC open. At times the machine will sit like this for several days, doing nothing at all. During an interval like that it's _possible_ (not certain, but _possible_) that i've rebooted the file server with the library files on it. During that server reboot there was zero (user initiated) MC activity. None. When i looked at the client machine again, all "Filename" fields were empty all of a sudden. The rest of the library was intact - i could search for tags, browse via view schemes, etc. .
I've had what you describe happen but only when MC was in the process of updating the library. In my case RAM was a bit bad so it would freeze the box requiring a hard boot. Any field that MC happened to be working on would be lost in its entirety for the whole library.
So i think that delayed write might have something to do with it. If MC is not doing anything why would the library get corrupted if a remote file server was rebooted.
Try it, i doubt you can make it happen on command, but if you pull the rug on MC when its doing something then what you described is very possible :)
-
I don't think this is going anywhere.