Hello people,

Came across a funny one today. I created some new playlists for some new MP3s I downloaded (http://chinesepod.com - trying to learn Mandarin)

Anyway, I created a new playlist in the root called Languages then a sub one called Chinese then chinesepod.com

Problem is that nothing below the Languages is showing up on the player but shows fine in both jemplode and in empeg web lite v0.60

Also if the I play the "empty" Languages playlist from the player, the files play just fine.

Using most recent alpha v3a11 and jemplode v70.

Any ideas before I start mucking around with firmware versions (about the only thing I can think of trying but which I don't think will make a difference anyway)?

Thanks

That is the expected behavior. There isn't any unicode support in the Empeg firmware. Your Chinese language playlists and MP3 tags will not show up.

I don't know the extent of unicode support in the 3.0 Alpha firmware. I think there might be some code in there for it, but it doesn't work 100 percent (IIRC), and there's no Chinese font. I think someone supplied a half-working Chinese font once, but I seem to recall that it was more of an experiment than a full implementation.

You assume that the tracks inside the playlist have Chinese names. It matches the symptoms to assume so, but we don't know that for sure.

In fact, we know for sure that they aren't. As seen in the Empeg Web Lite screenshot, the child of "Languages" is called "Chinese". There's nothing unusual about the word "Chinese", and it should be displayed. And in v3, unsupported Unicode characters appear as little squares; they don't disappear altogether.

Having said all that, I don't know what is going on here. Probably the database is corrupt in some peculiar way. But the Chinese-characters thing is definitely a red herring.

It does look a bit odd in the Empeg Web Lite picture that no length is listed for the "Languages" playlist. Is there normally a value there? If the database's "playlist" field is filled-in, but the "length" tag is zero, that might explain why different programs have different opinions on the playlist's contents.

Shonky, try deleting and rebuilding the database files, using the procedure listed in the FAQ under "My player takes a long time to boot and says it is Building Music Databases".

Peter

Actually, we don't. We know that the playlist isn't named with unicode characters. But the tracks might be. And if it can't show the tracks, mightn't it think the playlist was empty and not show it? Of course, you know more about the internal workings than I do.

Peter covered that with:

"And in v3, unsupported Unicode characters appear as little squares; they don't disappear altogether."

So it can show the tracks, even if the have Unicode characters that it doesn't have glyphs for.

Or at least one would assume that is what it would do

Hey guys,

Yeah there aren't any funny characters (at least in the first few MP3s I have loaded). Dr Tag did seem to have a few issues with some of the tags though. I've largely rewritten the tags with Dr Tag so they should be OK. The current ones all have English for all the fields I can see.

The "Chinese" playlist and "chinesepodcom" playlist were created by myself, by hand in jemplode using a normal English PC (i.e. no unicode or anything). That's probably the only difference I can think of compared to any other MP3 I've dropped into my empeg - normally my directory structure would create the playlists for me although I've definitely created manual playlists before with no issue.

My database is built correctly I'm fairly certain - have synced a few times actually trying a couple of things.

Even if the actual MP3s had unicode characters and the player couldn't display them, it should still show my "Chinese" playlist and my "chinesepodcom" playlist below that. There's actually another level below that called "A - Novice". Then it might display "- None -" in which case I could blame the tags.

Hmmm. Thought this was going to be a simple one and I'd done something silly.

At this point, then, I'd say that what's happened is that V3 Alpha has corrupted your playlist tree somehow. I had that happen a couple of times with the V3 alphas.

See if going back to 2.0 final and then rebuilding the databases by hand fixes the problem?

Won't that mess up the dynamic data partition? i.e. I'll have to back that up first?

Downgrading to v2 wo n't really prove anything though will it? The database is created everytime from the fids(?). If the fids are corrupted assuming that's what you're saying, v2 won't fix them magically will it? I'd have to create the playlists again?

And if something really is corrupted, why does jemplode and empeg web lite show them properly? It's reading the same data.

Also, why is the player actually playing the tracks? It seems to play them fine, they just don't show in the playlist.

OK. Here's the deal:

1) v2.01 firmware did nothing different

2) Rebuilding the database did nothing different

3) I created brand new playlists in jemplode and dropped a known non unicode tagged MP3. No dice.

4) Finally I created the full directory structure on my PC from the Language playlist down (i.e. Language->Chinese->chinesepod.com->A Novice) and it works.

So it would seem that when creating playlists in jemplode manually it's not doing it properly. I'm surprised if that's the case - I'm sure others would have done this. I probably have only ever created the root playlist which seems to work (i.e. the "Languages" one in this case).

When dropping a directory in to jemplode to create playlists it fills in fields like Artist and Album with "Various" eventhough you don't ever actually see them in normal operation. However this only happens if there is an MP3 in the directory. If you drop an empty directory structure it leaves the fields blank.

When creating a manual playlist in jemplode the only field filled in is Title (unless the user manually enters the fields).

Without these fields filled in the firmware doesn't seem to show them. I haven't got as far as figuring out which fields are actually required.

Because the hijack stuff and jemplode don't care about the blanks they work fine and they just follow the fids manually. The firmware doesn't like it though.

Sound familiar to anyone? I'm really surprised this hasn't been found before.