MediaMonkey forum

---------------------------
1. epic-ringtone - MediaMonkey
---------------------------
Assertion failure (M:\Sources\MediaMonkey401MM\MP3Datab\SQLiteDB.pas, line 1976)
---------------------------
OK
---------------------------





I have no M: Drive. I suspect this fault is somewhere within the code when related to having added the DBName line under [SYSTEM] in the AppData\Roaming\MediaMonkey\MediaMonkey.ini to direct it to my mapped drive location with the shared DB. Without the line there wasn't an error. It converted the DB from ver3 to ver4. then this error occured after it seemed to finish that task

What if you change the DBName path to the UNC Path instead of the mapped drive path?

can try that but the entire database is expecting the mapped drive. provides stability as I can move the collection to anywhere and just remap the drive. Will make a copy of the database and try it.

That doesn't matter, the DBName path is independent from paths to the music stored in the database. So you can change the DBName path without affecting your music.

However it is recommended to use UNC Paths for your media files as well. You might also find your music no longer plays in which case you should contact support.

using the UNC works to access the DB without error. With the DBname being a drive path it errors out. What would cause this? Database still has the drive path references and the music works fine. Z:\Music\

I would rather use the much more stable/controllable Drive path verses a weaker UNC path.

I don't have an M:, that has to come from MM code.

Actually the UNC path is stronger as mapped drives don't always initiate on time.

I suggest you send a debug log (step 4b) to support for the Mapped Drive DBName setting and explain that UNC Path does work: http://www.mediamonkey.com/forum/viewtopic.php?f=7&t=69

UNC is weaker is it does not allow for mobility or flexibility. with a mapped drive I can move the collection where ever I want, never need to rescan it to have it find the new location (which is unreliable at best). Mapped drives connect just find when handled from a server OS. It may be that is part of the problem in that MM isn't friendly toward server OSs. Although it should not care as MM isn't ever running on the server itself. Just the music collection and database sit on its drives. I simply alter the server initiated map command to the new location, it will then disconnect the drive on the client systems and reconnect it to the new point.

You can always use MediaMonkey to move files.

And mapped drives depend on driveID which Windows may change when it shouldn't which means the files no longer work in MediaMonkey. UNC Paths don't have a driveID and thus are more robust in MediaMonkey. Besides you can also change machines and maintain same UNC Path, or change folders and maintain same UNC Path.

Now I changed to back to the mapped drive location, and its happy as can be no error. One thing I did notice is that after 4 installed it said "converting, may take a few minutes". It finished in seconds, and came up blank.a 30meg DB.. blank? Unlikely. When I went looking for the INI file In AppData\Local, I saw it still had the correct drive path. But poked around and 4 seems to store it in AppData\Roaming now, that one didn't have the drivepath, once I changed that, the error showed up and still showed the one MP3 file(epic-ringtone) in now playing, Swapping to the UNC path cleared the error, swapping back to the mapped, all is well. A little odd, M: still has to come from code as the path is completely foreign to me. If I can ever recreate the problem I'll kick off a debug log.

Lowlander wrote:You can always use MediaMonkey to move files.

And mapped drives depend on driveID which Windows may change when it shouldn't which means the files no longer work in MediaMonkey. UNC Paths don't have a driveID and thus are more robust in MediaMonkey. Besides you can also change machines and maintain same UNC Path, or change folders and maintain same UNC Path.

UNC paths are to structured and can't be simply redirected as a mapped drive can with a simple command from server. Moving the data is not the same as changing machines. I have recently reorganized my data among various systems. redirecting the mapped drive from my server worked far better than anything else had a hope of doing. UNCs are weak in a domain style system. Perhaps under a workgroup such is true but even then not really.
Redirect the mapped drive and the software looking for the drive never knows the data moved. Mapped drives provide stability for software UNCs have no way to do. In a controlled environment, software is configured to look for DriveX, admins can then change where the data is for a server upgrade and only need to redirect the mapped drive. Not all software can respond to a command from a server to change options dictating where the data is. Writing a script to do it is possible but a real PITA.

Did you run complete database maintain or this error appear right after when database was converted (at MM startup) ?

I just installed 4.02 over 3.x and had the same message (with M:\) on first launch. Complete maintenance before upgrade.

.db file is on a ramdisk which is not mounted and music files are on the regular datadisk, not mapped nor mounted.

M:\ obviously looks like an absolute path. Rings no bell either: I never used that letter in years.

FWIW, the upgrade procedure took like 20 secs, created an "mm.db.Pre4" file which has the exact same size as the original MM.db (300mB). Looks like a copy to me, hence unusable to 4.x.

Funny my only complaint with MM over the years was with the unique drive id: I might have change hard disk 20 times since 2.5 ... I tried to mount a dedicated volume once, which MM seemed to be fine with, but I hate dedicating disks and waste resources.

Putting .db on a ramdisk saves disk access and some fragmentation, which MM does not like at all. Even without a ramdisk, I'd definitely store the db file outside of the WinDisk : this is valuable data that has to be backed up with the rest and has to be safe from a system restore.

I was hoping 4.x would be the time to get rid of this long time nail in the foot of one category of MM users : the one I belong to No luck this time. I'll look around before reverting, see if I can bring some clues, but the program looks unusable as such. One potential clue might be that I chose to install in a new folder instead of overwriting MM3 with all its incompatible scripts. Not sure this will help.

Happy end of the ... year
Rojer.

I installed 4.02 over 3.8 and got this error while trying to update the database. I got the M: drive too, and M would have been the next drive in my system. (No I did not do a complete system maintenance first not having any troubles with previous updates)The program runs but it won't display anything under Music on the right hand data tree even though it reads through the files upon opening. I can access my files by using the location feature but it will not build a dastabase. Could I just uninstall MM then reinstall fresh?

[quote="DMitchell"]The program runs but it won't display anything under Music on the right hand data tree[quote]
I am not dyslexic, just tired, I meant the left hand tree.

I'd suggest installing 4.0.3.1463: http://www.mediamonkey.com/forum/viewto ... 32#p326132

Then while MM is closed copy the old MM3 database to the MM4 database location and start MM: http://www.mediamonkey.com/support/inde ... ticleid=17

If you're willing you can install the debug version of MM 4.0.3.1463 and run DBGView: http://www.mediamonkey.com/forum/viewto ... ?f=6&t=341 Then start MM (after copying DB) and let it log the conversion. If it fails open a support ticket and attach the log and offer your MM3 DB for analysis.