PMM 3.92 goes catatonic - does this happen to you?

[jlv]

I have a hacked 120G DMS, with about 75G in use for about 16000 tracks.

Whenever I use PMM to 'Sync' new tracks to the DMS, it tends stop refreshing itself while 'working' - taking about about 2-3 hours to complete the 'Sync'.  While it's like this, process explorer shows it's doing about 32MB/s of reads and very little writes (under 32KB/s). It's also not reading/writing from the DMS (since the green light on the cradle isn't flashing). It's also consuming a whole core (I'm running XP MCE on a dual core).

This happens no matter how many tracks have been changed/added (1 or 5000).

After 2+ hours, it finishes whatever it's doing and then says "DMS has been sync'd" and then starts copying files. Tonight, there were about 1800 to copy.

When that's done, and I hit 'Save', it will pretty much do the same thing while generating voice prompts and updating playlists.

(I have only about 35 playlists... most are small except two containing 14500 tracks, once sorted by file path and once sorted by album)

I'm almost certain this is all I/O to the DB files under C:\Program Files\PhatNoise Media Manager\Data.  The 'PMM.db' is about 40MB and the 'pnrdbrw.db' is about 49MB.

Does this happen to anyone else?  Does PMM really suck this much?


In the past, I've deleted the whole DB and re-imported all my tracks, but it didn't help.  I never really noticed this problem until I got the larger drive.

[jlv]

FWIW... on the PHTDTA drive:

In \Profiles\Default, there are 167 files for playlists (the two big ones p0.m3u and p1.m3u are 1850KB), and:
In Albums, there are 4359 .idx files.
In Artists, there are 2875 .idx files.
In Genres, there are 104 .idx files.

in \tts there are 16941 .wav files.


Is this abnormal?

[jlv]

During 'Save', it's the 'Generating SQL database media lookup table' that takes a long time... it doesn't lock up PMM, but it takes a long time.  Right now it's reading at 125MB/s and writing 30KB/s.  In the filesystem, I can see its writing pnrdbrw.db-journal... it's at 18MB (of 49MB).  And that's not even on the DMS...

Perhaps I should move the PMM data directories off my C drive to a faster drive...

[sbingner]

That does seem a little excessive but I'm not sure how long that should take anymore....

[markbowen]

I have the same experience.  Once you get over a certain number of files on the DMS, on a save/eject PMM may appear to stop working for a long time, even though it is working.  Two to three hours sounds about right. 

It's not about the size of the DMS or the speed of the data directory drive.  I think it's just about how much is on the DMS.  When I started filling my 320GB DMS a little at a time, the save/eject process was very zippy.  But as I add more tracks, the process is taking longer and longer again.

Jlv, 14.500 tracks in a playlist might be too much.  It may be outdated and no longer relevant, but the Phatbox user's manual recommends no more than 9999 tracks per playlist.  I don't know that reducing the number will help, but it's worth a try.

[S80_UK]

Interesting. 

In contrast, I have "only" about 6,800 files on my 160GB DMS (it is very full) but spread over more than 400 playlists.  Saving takes just between 5 and 10 minutes.

[jlv]

Thanks for the responses.  I should add that in the past, I deleted both large playlists, but it still took forever to sync/save. Perhaps I should do that and wipe the DMS, so that there isn't any old playlist data.


Of course... the two large playlists are both 'all songs' (e.g., no audio books), one sorted by album and the other by artist. Depending upon my mood, I like go random through the playlist, and then if I get interested in an album or artist, take the random off and listen to more from the same album/artist.

Doesn't everyone end up with something like this?  How do you go random through all the tracks otherwise?
(this is how I've been using the Phatbox since I got it 5 years ago; I don't know if I've ever tried another way).

[Terry_Kennedy]

In contrast, I have "only" about 6,800 files on my 160GB DMS (it is very full) but spread over more than 400 playlists.  Saving takes just between 5 and 10 minutes.

2344 MP3 files / playlists here (I'm using the one MP3 file per disc with the Phatbox track seek hack), using about 212GB on a 250GB DMS.

However - I'm using the older Music Manager, version 2.35. I don't use it for anything but bulk signing of the playlists and generating the index files - I populate the DMS directly, then start PMM, select the DMS, and do an immediate save and exit, which signs the playlists, etc.

I did find that on some systems the DMS/cradle were configured by Windows with write caching disabled, which slowed down things like bulk deletes on the DMS.

[markbowen]

Thanks, Terry!  That simple tip about write caching made all the difference in my case.  I'd not even thought to check it before, but sure enough, write caching was disabled.  With the caching enabled, the save/eject on my 320GB DMS (12,718 tracks, 198 playlists, 100GB used) took only 14 minutes.  It used to be the database ops that took forever, but now that takes no time at all.  Jlv, this may be worth checking, too.

[kegger]

Great find Terry!  That definitely improved save and eject time on the back, rivals my 120gb now.  Too bad the front (initial recognition of DMS) doesn't work that way with a 320gb!  Nevertheless, thanks again for the tip!

[jlv]

Mine didn't have write caching enabled, either -- but that's only the 2nd point where PMM goes catatonic.  Fixing that certainly helped the final eject performance../

But the PMM goes catatonic while computing what files to sync -- and as I said above, it isn't writing to the Phatbox at the time.  It's spending all of it's time reading.  Tracing it with 'filemon' (from sysinternals.com) shows that all the I/O is going to the SQLlite database 'pnrdbrw.db' in C:\Program Files\PhatNoise Media Manager\Data\06eee551ce4cc9545b47f878ea03b078; almost all reads with a few writes (and a few writes to pnrdbrw.db-journal).  That's the database PMM keeps for what's on the Phatbox.

When the initial compare of the sync is done (and it starts to copy new/updated files to the Phatbox), this database ends up at about 56802 KB.  That's slightly larger than the 42279 KB it is using for PMM.db, database it makes for the files on my PC (on drive Q:\).

Is SQLlite messed up for me?

[VorTechS]

It won't be messed up, but PhatNoiseMM is based on SQLite 2.x which was obviously a fairly early version.

All I can suggest, is that you keep half an eye open for the next version of PhatHackMM which we think addresses all the known issues that we've got on the PhatBox writing side as we have no issues with large drives.