INTERACT FORUM
More => Old Versions => Media Center 11 (Development Ended) => Topic started by: marko on March 03, 2006, 09:25:25 pm
-
these are beginning to crop up more regularly. there are more, I'll add them when I find them. if we get enough people with the problem in one thread, we might be able to find out why.
[name] (Psyffer23: 20 Feb. 2006) (http://yabb.jriver.com/interact/index.php?topic=32127.0)
[album] (nunisimo: 04 Mar. 2006) (http://yabb.jriver.com/interact/index.php?topic=32366.0)
[comment] (dnj: 04 Mar. 2006) (http://yabb.jriver.com/interact/index.php?topic=32127.msg222186#msg222186)
-
If you see this, please make sure you have the latest version. There was a multi-threaded DB access issue found and fixed around build 11.1.126.
It was a theoretical problem (we couldn't cause a real-world problem from it), but none-the-less it's possible it is to blame for these reports.
-
I have about 6500 files missing [Name] tag and a few networked files missing all tags.
With library server acting up and some kind of malevolent reaction to ffdshow my wife has been less than impressed with MC in the past 2 weeks
Media Center Registered 11.1.139 -- C:\Program Files (x86)\J River\Media Center 11\
Workstation 5.2 Service Pack 1 (Build 3790)
AMD Unknown 2480 MHz MMX / Memory: Total - 1047 MB, Free - 450 MB
Internet Explorer: 6.0.3790.1830 / ComCtl32.dll: 5.82.3790 / Shlwapi.dll: 6.0.3790 / Shell32.dll: 6.0.3790 / wnaspi32.dll: N/A
Ripping / Drive D: _NEC DVD_RW ND-3520AW Mode:ModeSecure Type:Auto Speed:Max
Drive E: Mode:Normal Type:Auto Speed:Max
Digital playback: Yes / Use YADB: Yes / Get cover art: Yes / Calc replay gain: Yes / Copy volume: 32767
Eject after ripping: Yes / Play sound after ripping: No
Burning / Drive D: _NEC DVD_RW ND-3520AW Addr: 0:1:0 Speed:16 MaxSpeed:17 BurnProof:Yes
Test mode: No / Eject after writing: Yes / Direct decoding: Yes / Write CD-Text: Yes
Use playback settings: No /
-
I have found that the database never loses information if the system is stable and no crashes happen.
All library fields are stored in separate .jmd files. MC can lose field info if it crashes before a write operation is complete. I think MC lacks a mechanism that could detect an incomplete "field".jmd file and restore the previous good file.
Personally, I make a library backup always before making database changes. If a crash has occurred for some reason I restore a backup and recreate the last changes instead of trying to check if the library survived from the crash.
-
I aggree, I loaded an older library and the tags are now "back".
Dr. C
-
I think MC lacks a mechanism that could detect an incomplete "field".jmd file and restore the previous good file.
I've hinted at this in other posts, some way to integrity check the library.
-
Anyone who has seen this, are you using Audioscrobbler? Any other third-party plug-ins?
A bug in a third-party plugin that causes a crash could definitely account for this problem.
-
I have about 6500 files missing [Name] tag and a few networked files missing all tags.
The crashes you report in this thread could be related:
http://yabb.jriver.com/interact/index.php?topic=32392.msg222222#msg222222
-
I have about 6500 files missing [Name] tag and a few networked files missing all tags.
Is it just database tags or is it tags in the files as well?
If it's in the files too, what are the modified dates? That will give you an idea of when it started and how long it's being going on for.
-
AFAIK, this kind of sudden data loss is always related to corrupted jmd files (database only). The user would need to apply the database changes to the disk files after a restart for making the physical file tags corrupted too.
One would like to think that if MC could write a checksum to the end of the .jmd files, keep temp copies of the original .jmd files during a write operation and delete the original files only after checking the new files the problem would be solved. Naturally MC should be able to restore any corrupted files after a program crash. Only the latest changes would be lost.
-
When I restored the library to a backup and checked the tags (from within MC) I assumed that meant that the tags were okay and the database was corrupt.
Dr. C
-
One would like to think that if MC could write a checksum to the end of the .jmd files, keep temp copies of the original .jmd files during a write operation and delete the original files only after checking the new files the problem would be solved. Naturally MC should be able to restore any corrupted files after a program crash. Only the latest changes would be lost.
A mechanism like this is already in place. Media Center's database engine is designed so that unplugging your computer's power cable at any point can not cause substantial data loss. The database also makes automatic scheduled backups.
There may be something else at play, but we have not been able to reproduce it. It's not clear whether something is explicitly changing values (plugin or some tagging method in MC), there's a hardware problem, or there's a database bug.
Thanks.
-
A mechanism like this is already in place. Media Center's database engine is designed so that unplugging your computer's power cable at any point can not cause substantial data loss.
Oh, I didn't know that. I must have missed the proud announcement... :)
Am I correct if I assume that MC11.0 didn't have such a mechanism? After losing field information a couple of times with MC11.0 I have always restored a backup after a crash.
-
A mechanism like this is already in place. Media Center's database engine is designed so that unplugging your computer's power cable at any point can not cause substantial data loss. The database also makes automatic scheduled backups.
I've noticed error messages on startup some times when this happens, other times not. But a cursory look at the main library shows a tag(s) entirely missing, failed write to a .jmd file i suspect.
An easy way to reproduce this is cut the power while MC is making tag changes. I've not noticed any problems if power loss occurs during playback.
I'm not certain if MC can protect against such an event, so standard practice is to deliberately restore from a previous known good backup whether i notice a discrepancy or not. I save important tags to the files themselves so i don't lose too much.
I would like the option to turn off automatic backups as it slows things down a bit during tagging. I almost never trust the automatic backup in case of a problem preferring to resort to a previous manual copy, library backups being as fast as they are.
-
Anyone who has seen this, are you using Audioscrobbler? Any other third-party plug-ins?
-
Nope, just stock MC11.1. I told everybody this was a problem almost 2 months ago and never, ever happened in MC11.0, 10 or 9..
-
Thanks, Lisa. What third party plug-ins do you use?
-
No audioscrobation, but I am usng PlayingNow.
tnks
Dr. C
-
No audioscrobation, but I am usng PlayingNow.
Did you ever use others?
-
Nope. I have always used just use 2 plugins...Library Server and the 3rd party Playing Now by J. Dickson.
Dr. C
-
Nope, just stock MC11.1. I told everybody this was a problem almost 2 months ago and never, ever happened in MC11.0, 10 or 9..
Doesn't look like a 3rd party plugin problem then.
-
Hmmm, I've seen this in the 11.1 builds but never use MC for tagging, so it would be limited to what had been played.
Do I use plugins? Yes, I do.
However, I do not use format plugins (directshow, flac, etc) that could possible write to files. I also do not use tagging plugins.
Until recently, I used the AS plugin and the MSN plugin.
Neither of those have any options to write ratings or anything else.
So, how would those erase library data?
-
Until recently, I used the AS plugin and the MSN plugin.
Neither of those have any options to write ratings or anything else.
FYI ... PN can update the ratings tag if you use a ratings skin and you select a rating. Did you encounter this problem prior to using PN?
-
FYI ... PN can update the ratings tag if you use a ratings skin and you select a rating. Did you encounter this problem prior to using PN?
No, haven't had the problem since installing PN 1.3
Did not have PN installed before that version.
It's why I took pains to point out that I had nothing that should be writing/changing anything be it file or database.
-
I have observed:
1. Tiles with numbers for album names
2. Tags combined and in wrong places (freshly imported files tagged correctly by someone else)
3. Crash upon restore previous library
-
It's why I took pains to point out that I had nothing that should be writing/changing anything be it file or database.
A virus checker?
-
Jim,
The only 3rd Party I had installed then (or use normally)....
How about any others you have used, normally or not?
-
A virus checker?
Yep, and it isn't even looking at the data drive. I'd be hard pressed to imagine the situation that something that is reading a file (virus checker) would corrupt it.
But, as I said, why would an app or plugin that has no write feature take tags from the library? Or from the file itself?
In my case, I use only a few smartlists so I can easily rebuild the library. I do no tagging so there is no need for MC to ever write to my files.
So far, the only thing I've lost has been tags within the library. Clearing the library and importing does the trick for me.
I had little luck with update library from tags when this happens which leads me to believe the library itself is corrupted but not badly enough to refuse to load.
Next time around, I'll get a library backup and make it available.
-
Same problem here, track name just disappeared after .136 was installed. Just installed .139, still no track names.
Went back to a backup from before .136, all the track names are there.
No third party plug-ins, no Audioscrobbler, but I do run AVG Free, and have been for quite some time.
-
LisaRCT--
Are you refering to that bug in certain 11.0.xxx builds where mp3 web streams would eat the "name" tag of the following track? I recall that being an issue under that exact circumstance, but it was quickly fixed.
FWIW, I haven't noticed any disappearing tags, and I believe I would be as vulnerable as anyone to unaccountable loss of data, or socks and gloves, for that matter.
-
Does anyone have a backup of a library with missing data? Thanks.
-
Maybe it's a completely different cause, but just to mention that the problem of missing tags is not new and was already reported about a year ago (MC 11.0).
I experienced the problem twice at that time. In both cases I had previously killed MC from task manager.
http://yabb.jriver.com/interact/index.php?topic=26350.msg182672#msg182672
-
Hopefully this will be put to bed next build:
Fixed: If Media Center ran out of disk space or encountered a memory error while saving a database field, the field could become corrupted.
To reiterate, while it's not recommended, hard-killing MC should never cause data corruption other than the possible loss of a few minutes work. (we continually hard-kill the application during development, so this is important to us)
Thanks everyone.