songs.gdb growing, when my MP3 library isn’t?

[GICarey]

Hi folks,

Setup:
* NSLU2 running at ~ 500mhz (a Jan 07 build @ stock speed, they’ve obviously changed something in the atest batch, sadly still on 32mb RAM though)
* Unslung to a 1gb Memory Stick
* mt-daapd package from the Unslung repository (0.2.4)
* 300gb Maxtor drive running a 512mb Swap partition, remainder NTFS
* about 8000 songs on the NTFS partition

So, configured Firefly, iTunes is happy (now that I’ve got round the router/multicast trap), speed fine and everything working lovely.

However, poking around, I notice that the songs.gdb file grows upon each restart of the Firefly server, grows by the size of the file when it’s first newly generated, so I’m guessing that what is happening is something like a rescan appends the database onto the end of the old one? rather than replacing / updating (my library of MP3s is unchanged since the day it was first added)?

Normal behavior? an oddity? Any ideas?

Cheers, and keep up the good work!

Gav.

[rpedde]

@GICarey wrote:

However, poking around, I notice that the songs.gdb file grows upon each restart of the Firefly server, grows by the size of the file when it’s first newly generated, so I’m guessing that what is happening is something like a rescan appends the database onto the end of the old one? rather than replacing / updating (my library of MP3s is unchanged since the day it was first added)?

Right. My guess on that would be that when it first starts the drive isn’t mounted, so it empties the database, then next scan it’s there, so it populates the database again.

You can always safely delete the songs.gdb to force a full scan. Maybe even add it to the S60mt-daapd startup script in /opt/etc/init.d.

Or, upgrade to nightlies. That does a vacuum on startup to get rid of unused disk space.

— Ron

[mas]

NSLU2 running at ~ 500mhz (a Jan 07 build @ stock speed

Really? Is it only a timing change or is that new version now really faster? Has anyone else observed this? My NSLU runs still at 266 Mhz. Manually de-underclocked.

[GICarey]

@mas wrote:

Really? Is it only a timing change or is that new version now really faster? Has anyone else observed this? My NSLU runs still at 266 Mhz. Manually de-underclocked.

Well, having done nothing barring unslinging, i’m showing 500 odd bogomips. Clock isn’t running faster or anything to suggest a timing error.

Few details from the system here: http://www.pastebin.ca/479715

Happy to perform any tests to confirm/deny it tho.

[GICarey]

@rpedde wrote:

Right. My guess on that would be that when it first starts the drive isn’t mounted, so it empties the database, then next scan it’s there, so it populates the database again.

You can always safely delete the songs.gdb to force a full scan. Maybe even add it to the S60mt-daapd startup script in /opt/etc/init.d.

Sounds entirely plausible. I dont intend to restart the NSLU2 too often, so i’ll just go with the manual deletion now-&-again.

May move to nightlies at some point also. Especially if/when UPnP is all working (or, ready to test), as I’d like to try it with my Nokia N80 phone (has 802.11g & a UPnP media player..)

[fizze]

@GICarey wrote:

@mas wrote:

Really? Is it only a timing change or is that new version now really faster? Has anyone else observed this? My NSLU runs still at 266 Mhz. Manually de-underclocked.

Well, having done nothing barring unslinging, i’m showing 500 odd bogomips. Clock isn’t running faster or anything to suggest a timing error.

Few details from the system here: http://www.pastebin.ca/479715

Happy to perform any tests to confirm/deny it tho.

Interesting. Since my slug runs at 266Mhz and shows exactly half bogomips. (remember, bogo actually is short for “Bogus” ;))

Hm, I guess you could try to run LMbench or nbench to get some numbers and compare these with the wiki on http://www.nslu2-linux.org/wiki/HowTo/OverClockTheSlug

[Author]

Posts