Freshly RB'd Clip+: some Qs

[mouthwatering]

I've just RB'd my 8+16gb Clip+ and so far I am pretty happy with the results. The usability is much improved (not least because RB fonts are smaller and allow for more screen lines). Kudos to the devs for a great piece of software.

Anyway, I still have a few questions where I couldn't find answers in the docs or online.

1. I have about 12k tracks (64kb WMA VBR) on the player and navigating them via "Files" seems to work all right (I have not checked all these tracks, obviously). The "Database" feature works, sort of, but stops indexing tracks when it reaches ~track 9820. The player then hangs and the only way out is pressing OFF until it switches off. Upon switching on, no database entries (or database files) exist. Any ideas?

2. In the "Files" menu I have two entries "##MUSIC#" and "##PORT#". What are these for?

3. Is there a way to configure the RockboxUI to load native codecs? The Clip+ RockboxUI tries to load the standard WMA codec but as this is Clip+ firmware and not x86 code, it won't load. I've seen that RockboxUI copies the required codec to a temp DLL and tries to load that, so I speculated it might be possible to "smuggle in" the required codec DLL by copying it into the codecs directory.

Thanks for any hints...

Cheers wm

[CrowdAds]

[dfkt]

1.) Increase the file limits for the database. Here's the manual, how the Rockbox database works: http://download.rockbox.org/daily/ma...#x7-470004.2.3

2.) Those are remnants from Sandisk stock firmware MTP mode. As long as USB is handled via stock firmware, those folders get re-created everytime the player is plugged into a PC. Once USB is handled via Rockbox, you can delete those for good.

3.) I have absolutely no idea what you mean by that. RockboxUI? Loads codecs? You mean the Rockbox simulator that runs on Windows? It's just a simulator to develop WPS screens, to roughly try out how Rockbox handles before installing, etc - but it's not a 100% emulator of a real player by any means.

[mouthwatering]

Originally Posted by dfkt

1.) Increase the file limits for the database. Here's the manual, how the Rockbox database works: http://download.rockbox.org/daily/ma...#x7-470004.2.3

I RTFM and I certainly tried that (among a few other things) before posting. I set the limits way beyond the number of actual tracks on the device and the database indexing still hangs at track no 9820.

Originally Posted by dfkt

2.) Those are remnants from Sandisk stock firmware MTP mode. As long as USB is handled via stock firmware, those folders get re-created everytime the player is plugged into a PC. Once USB is handled via Rockbox, you can delete those for good.

THX.

Originally Posted by dfkt

3.) I have absolutely no idea what you mean by that. RockboxUI? Loads codecs? You mean the Rockbox simulator that runs on Windows?

Yes.

Originally Posted by dfkt

It's just a simulator to develop WPS screens, to roughly try out how Rockbox handles before installing, etc - but it's not a 100% emulator of a real player by any means.

I know that it's not a 100% emulator. However, the simulator clearly tries to load a DLL with the codec -- of course the codecs used by the emulator are compiled for the Sandisk device and not for x86 CPUs. So I thought this was worth a shot. Never mind, I'll further investigate on my own.

Here's another question: the Rockbox site lists four different flavours for development under Windows. I know my C but I am not a proficient Linux system programmer. What's the preference among those of you who do RB development under Windows?

Cheers wm

[saratoga]

Originally Posted by mouthwatering

3. Is there a way to configure the RockboxUI to load native codecs? The Clip+ RockboxUI tries to load the standard WMA codec but as this is Clip+ firmware and not x86 code, it won't load. I've seen that RockboxUI copies the required codec to a temp DLL and tries to load that, so I speculated it might be possible to "smuggle in" the required codec DLL by copying it into the codecs directory.

Originally Posted by mouthwatering

I know that it's not a 100% emulator. However, the simulator clearly tries to load a DLL with the codec -- of course the codecs used by the emulator are compiled for the Sandisk device and not for x86 CPUs. So I thought this was worth a shot. Never mind, I'll further investigate on my own.

Its not an emulator at all. Its a port of rockbox to unix/windows. Everything is recompiled for the target CPU, in your case x86.

Did you install a copy of rockbox for the clip over the simulator? I'm not sure exactly what that would do, but I expect it will break things quite badly.

Originally Posted by mouthwatering

Here's another question: the Rockbox site lists four different flavours for development under Windows. I know my C but I am not a proficient Linux system programmer. What's the preference among those of you who do RB development under Windows?

vmware is the fastest and easiest way. cygwin is also an option, but its extremely slow.

[mouthwatering]

Originally Posted by saratoga

Did you install a copy of rockbox for the clip over the simulator? I'm not sure exactly what that would do, but I expect it will break things quite badly.

That's exactly what happened. I just wanted to copy the settings from the actual player to the simulator and somehow (PEBKAC) managed to copy quite a bit more than that, ie the codec subdirectory. Now fixed and it's working. THX for the heads up.

Originally Posted by saratoga

vmware is the fastest and easiest way. cygwin is also an option, but its extremely slow.

Good to know. I already have a VirtualBox setup so I will probably take the virtual machine route.

Still stumped as to why the database indexing would hang after 9820 tracks. NBD really as folder navigation suits me well but still I'd like to know why it doesn't work.

Cheers wm

[saratoga]

Originally Posted by mouthwatering

1. I have about 12k tracks (64kb WMA VBR) on the player and navigating them via "Files" seems to work all right (I have not checked all these tracks, obviously). The "Database" feature works, sort of, but stops indexing tracks when it reaches ~track 9820. The player then hangs and the only way out is pressing OFF until it switches off. Upon switching on, no database entries (or database files) exist. Any ideas?

Sorry missed this. My guess would be you have a corrupted file in there somewhere that hangs the ASF parser. Running your files through the sim might give some debug info. Alternatively, you can divide them in two, put a database.ignore file in one folder, and then binary search until you find the file (which would be useful to see if you can find it).

[Confuseling]

Am I right in saying that tags sometimes trip up the database too? Might be worth running them through some tagging software quickly to see if anything shows up before embarking on the bisecting mission...

(although I don't know if there is tagging software that will batch process tens of thousands of files, because I don't use tags or databases - just an idea...)

[mouthwatering]

Originally Posted by saratoga

Sorry missed this. My guess would be you have a corrupted file in there somewhere that hangs the ASF parser. Running your files through the sim might give some debug info. Alternatively, you can divide them in two, put a database.ignore file in one folder, and then binary search until you find the file (which would be useful to see if you can find it).

Hm... that's exactly what I didn't want to hear but expected to hear. My tags tend to be well-cared for but there's always the possibility of a rogue.
The only thing that immediately springs to mind would be some eastern European songs with non-ISO8859-1 characters.
I will check that, but other than that I'm afraid I'll have to resort to some serious file dissecting. Or just leave the database off;-)

Originally Posted by Confuseling

(although I don't know if there is tagging software that will batch process tens of thousands of files, because I don't use tags or databases - just an idea...)

MP3tag does that and a whole lot more, see http://www.mp3tag.de/en/index.html Great piece of software... and free.

Thanks for the hints. I'll post if I find out more.

Cheers wm

[saratoga]

Different codepages aren't going to matter. The metadata parser just memcpy's things, it doesn't actually try to look at the contents. More likely to cause problems are things with corrupted ASF containers, non-standard or corrupted tags, or things that aren't ASF with a .wma extension.

[dfkt]

I had corrupted audio and video files in the past - they always were ASF/WMV/WMA, never any other container... something's clearly not right with Microsoft's junk there.

[mouthwatering]

Originally Posted by saratoga

Different codepages aren't going to matter. The metadata parser just memcpy's things, it doesn't actually try to look at the contents. More likely to cause problems are things with corrupted ASF containers, non-standard or corrupted tags, or things that aren't ASF with a .wma extension.

I've found the culprit. A single track had NO tag information at all (though the same file on my main machine is OK, so there must have been a glitch while copying to the Clip+... go figure). Why missing tag information hangs the database indexer is another matter, but at least it works now.

A hint for those with similar problems: if you start indexing the database and it just hangs at some point, you may able to see the file (or the directory) causing the hang in \System\Debug\View database info.

At least I was, and it saved me a whole lot of work. (I know the debug menu should be off-limits, but then a hanging machine is a provocation...).

So until the next glitch all is well;-) Again thanks to all who helped.

Cheers wm

[Confuseling]

Originally Posted by mouthwatering

...(I know the debug menu should be off-limits, but then a hanging machine is a provocation...).

Well, in all fairness, sticking a designed from the ground up open source alternative firmware on your nice new MP3 player probably *should* be off limits, so that particular horse may have already bolted...

[mouthwatering]

Originally Posted by Confuseling

Well, in all fairness, sticking an open source alternative firmware designed from the ground up on your nice new MP3 player probably *should* be off limits, so that particular horse may have already bolted...

Agreed. Perhaps people who put an unstable alternative firmware on some device shouldn't be lectured about what or what not to do with it. Then again, many people do things without the slightest idea what they're doing;-)

I wrote that partly tongue-in-cheek and partly so that someone who opens the debug menu and then has their player catching fire doesn't sue me.

Cheers wm

[saratoga]

Originally Posted by mouthwatering

I've found the culprit. A single track had NO tag information at all (though the same file on my main machine is OK, so there must have been a glitch while copying to the Clip+... go figure). Why missing tag information hangs the database indexer is another matter, but at least it works now.

A hint for those with similar problems: if you start indexing the database and it just hangs at some point, you may able to see the file (or the directory) causing the hang in \System\Debug\View database info.

At least I was, and it saved me a whole lot of work. (I know the debug menu should be off-limits, but then a hanging machine is a provocation...).

So until the next glitch all is well;-) Again thanks to all who helped.

Cheers wm

Can you give me that file? If its under 2MB, a bug report here is probably the easiest way:

http://www.rockbox.org/tracker/index.php?type=2

Otherwise let me know and i can send you my email or something.

[mouthwatering]

Originally Posted by saratoga

Can you give me that file? If its under 2MB, a bug report here is probably the easiest way:

http://www.rockbox.org/tracker/index.php?type=2

Otherwise let me know and i can send you my email or something.

Sorry, too late. I was so keen to test whether this was actually the problem that I simply copied the good version from my machine to the Clip+ w/o before saving the damaged file.

But if it happens again or if I can reconstruct the problem I'll send you something.

Cheers wm

[saratoga]

Thats unfortunate, I'd like to fix any bugs in our metadata parsers so that the database becomes more stable.

[mouthwatering]

Originally Posted by dfkt

1.) Increase the file limits for the database. Here's the manual, how the Rockbox database works: http://download.rockbox.org/daily/ma...#x7-470004.2.3

Upon re-reading the relevant parts of the manual I think the limits this section is referring to have nothing whatsoever to do with the *indexing* (ie the creation) of the database. In other words, database initialisation should always work w/o having to fiddle with the limits. I may be wrong but in this case the documentation could be clearer.

I still have two questions WRT the limits. The docs say this:

"Max Entries in File Browser ... controls the limit on the number of files that you can put in any particular directory in the file browser."

I take it that "file browser" here means the non-database-driven Files menu but NOT browsing via the database? And that this limit works on a per-directory, non-recursive basis?

Cheers wm

[saratoga]

Yeah the file browser is the view of the hard disk.

The database is actually a bunch of dynamically generated playlists, which is why it mentions the playlist limit settings. I don't think the file browser settings impact the database though, so that should probably be reworded.