Perhaps we can collect a list of issues we find here, now that we have something to play with?

Not so much as a list of stuff to bug the busy people about, but so we know amongst ourselves what to expect.

Looks like crossfade also happens when you ffwd over a track, don't know if that's intentional or not. There was another I noticed, I'll haave to remember now what it was. Sigh.

Maybe before we go crazy, one of the original alpha peeps could dump a list of the already well-known bugs...

• Uploading with emplode 2.00-final often results in early termination causing a messed-up database (for me at least).
• Emplode provided with v3a3 is unstable.
• Crossfade kicks ass
• The player usually stops responding after playing a short (5-10 second) track when crossfade is enabled. (not tested without crossfade enabled)
• Reversing (possibly fast forward or both) past a track boundry crashes the player (I think).
• Crossfade rules
• Hard drives seem to not spin-down after the ignition is cut. It is possible the hard drives are always spun-up.
• Hitting fast forward quickly through 5-10 tracks will cause the player to stop playing.

I think those are pretty accurate.

Low bitrate files tend to stop playback (player will still take commands, but no output): step to another track and reboot.

/Michael

Low bitrate files tend to stop playback (player will still take commands, but no output): step to another track and reboot.

I noticed this. Anyone experimentally determined what "low" is?

Anyone experimentally determined what "low" is?


I've had it happen at 64 KBPS.

I also noticed that when I installed 3.0 and tried to run it with the Emplode 3.0 the results were not good, as has been reported above. 2.0 Emplode seems to work OK. I don't know if it was my adventure with 3.0 emplode, or if this will happen to everyone who tries it... but I went from 2.0 player software to 3.0 player software and reverted back to 2.0 player software because of the low bitrate problems (audioboooks) and in the process, my play counts got destroyed. According to the info in my player, I had only listened to La Villa Strangiato a total of two times, and I had actually played it more times than that just on that very day!

tanstaafl.

my play counts got destroyed

This was known before the "leak" and has happened to others.

This was known before the "leak" and has happened to others.


Ah, good. I'm glad to know it wasn't because I did something dumb.

It wouldn't matter to me, really, except that I have a custom shuffle set up in my player, shuffled in order of most often played. This lets me do a down-down-down keypress and have an instant "favorites" playlist.

In another few months I will have played my favorites enough that they will once again be back on top of the play count list, and my favorites playlist will work again.

Is there any way to hasten this? Is there a way to just reset all my play counts to zero?

tanstaafl.

Is there a way to just reset all my play counts to zero?

Yes, right here.

However, this brings up a very important question for the Cambridge folks...

The instructions linked above were for version 2.0. Which should be fine for you, Doug, since that's what you're running. But now that 3.0 is out, do those instructions still count?

Anyone?

I wouldn't recommend someone running that command until we get the new info on the dynamic partition. Based on experiences of moving from 2.0 to 3.0 and back, things have changed out there quite a bit.

Crossfade does indeed kick some serious bootay, but I just found an issue with it.

It doesn't work with ogg files. Well, not completely anyway...

You can fade out of an ogg, but you can't fade into one.

Let me explain.

If you're playing an ogg file, and then an mp3 comes on, the crossfade works just fine.

But If you're playing an mp3 file (or an ogg), and an ogg file comes up next, then there's no crossfade.



Anyone else seen this?

Oh yeah, one other thing I noticed...

Sometimes, when I first turn on the player, the fade in takes hella days... like 30 seconds or so. I'm guessing it's not supposed to do that.

But it doesn't seem to happen every time.

Also note that the last time it happened, it was playing an ogg file... so that may be realated.

Speaking of play counts... Is there any way to get rid of that counter in 3.0?

I had removed it before with 2.0, but I can't remember how I did it now... (Was there an option in Emplode before...?)

b0rked avatar fixed. yay.

Hey, at least this is the bug section...

Yeah, play counts on the track screen was an option in 2.0 final.

Note that you guys are going to find a lot of little things like that... Features that aren't in 3.0 because they were implemented late in 2.0, bugs that were fixed late in 2.0 that aren't fixed in 3.0, etc.

The reason is that 3.0 is from a branch earlier up the tree than 2.0 final. So there's a lot of rollup work to do.

If they ever get time to do it...

Anyone else seen this?

Yeah, but with my wma files. I noted it in the other thread and then realized I should have stuck it here instead.

Same behavior as you're describing, only with wma files. mp3s work fine.

This threw me for a loop at first because the cross fading seemed to only be working intermittently. In fact, the first few files I tried were wmas, so I really thought the cross fading wasn't that great (since the effect I was getting was a fade out and an abrupt entrance in). Finally I hit my mp3s (the bulk of my collection) and started hearing true cross fading. It took me a while to figure out exactly what was going on. Since my wma's comprise < 1% of my collection it shouldn't be too much of a problem to re-encode them if that's necessary.

The PrevVisual function doesn't work -- cannot seek backwards when cycling through the Visuals. If I recall correclty, this was implemented via a serial port command.

Cheers

Some bugs i found are:

on reverse seek, the cross fading seems to crash the player.

when looking at the seek tool and holding the seek buttons, if you go past the end of the song and into the next, it crashes the player.

When listening to a track, I put it in pause mode, and then click to the next track. But then when i unpause, insted of starting fresh at the beginning of the track, it plays part of the last track while starting the new track. They need to make it so when you click to the next track, it clears the crossfading buffer (of whatever its called, you know what i mean).


Simple wish list:
Fade on pause and resume, or give the option, so you can at least fade back in from pause.

when i say crash the player, the screen still looks ok, but you get no sound, and the time doens't count up, just sits at zero.

Bedies that, its quite stable. I was expecting it to be a lot worse!

Actually, PrevVisual was a virtual button code in v2final, not a serial command.

Hijack v342 now includes a temporary work-around for this issue, requiring either a Tuner or "fake_tuner=1" in config.ini.

Cheers

tanstaafl: Is there a way to just reset all my play counts to zero?

tfabris: Yes, right here.

FAQ: ... shell prompt to run the following command: dd if=/dev/zero bs=512 skip=4096 count=28672 of=/dev/hda3

This should erase the per-song dynamic data without harming the player settings such as the tuner and EQ presets.

I don't promise that this will happen to everybody (don't know why it wouldn't) but the above step did erase my EQ presets and bookmarks, as well as zeroing out my play counters.

tanstaafl.

The dynamic data partition hasn't changed much from v2 yet. I will change by 3.0 final, I'm sure.

but the above step did erase my EQ presets and bookmarks, as well as zeroing out my play counters.

Anyone know why this happened? It wasn't supposed to erase anything but his song statistics, according to the source that supplied us with the command.

Anyone know why this happened?

Could it have anything to do with the fact that I went from 2.0 Final to 3.0 Alpha and back to 2.0 Final? (This is what wrecked my play counters in the first place...)

tanstaafl.

The song counts really use 28672*512 bytes? Wow, that sounds inefficient.

This should erase the per-song dynamic data without harming the player settings such as the tuner and EQ presets.

I imagine that includes the data used to visualise tracks in seek mode.

Each song doesn't use up the entire 512 bytes that it's allocated. I think there has been mention of splitting it up further and allowing more track metadata to be stored so you can have more tracks. This would be one of the post 3.0 things which would break the dynamic data partition format.

I'll have to find my notes before I can comment intelligently, but it should be possible to determine if it will clobber those. I'll look in a bit.

I will change by 3.0 final, I'm sure.

...Yeah, but will It??

Sorry.

My issues with the 3.00alpha are as follows:
1. Stops dead on MP2's
2. Stops dead - I've now established that it's not just on low bitrate, it did it on a VBR, yesterday.
3. Forgets filters on re-boot.
4. I've given up trying to figure out whether the RDS issues are the Empeg, or the transmitted signal - it was never a great piece of technology! Since installing 3.00 I haven't had a single traffic announcement, but I seldom got them on 2.00.
5. Seldom syncs correctly.

If you do a tweak by artist, and get the "no matching artist found" message then the current song cannot be changed, pressing the skip buttons on the front panel causes the title information to change, but it doesn't change what is playing. Also when the playing song reaches the end you just get silence, even though it is not the end of the playlist.