Anyone experienced problems with sound dropouts during playback of wave files on their Empeg? I get this problem quite a bit (once or twice/per song) and don't know if it's due to the hard drive not keeping up or if the CPU is overburdened for some reason. The dropouts happen in random places and mainly with wave files, but very occasionally during searches with playback of even MP3 files. Hijack is giving a load average of 2.13 during wave playback if that helps any. I've also noticed that visuals lose their fluidity while the drive is being accessed whether for waves or MP3s. I am running 2.13b of the software, if that helps.

Also, does one need to defragment the drives on the Empeg or other Linux based machine is done with Windows?

Stu

The ext2 filesystem generally doesn't need to be defragged (though I believe there's a utility available) - I've got a partition for my news spool that after three+ years of use is still less than 7% fragmented.

/Michael

Constantly. Every time the drop out/skipping occurs, I hear the empeg access the disk. However, every time it accesses the disk does not cause it to skip. This only happens with WAV files, and unfortunately, I have a bunch of WAV files I like to listen to, and having it skip all the time is rather annoying.

I reported this problem last year. The problem is definitely not as bad as it used to be, where it would skip every time it accesses the disk. But it still skips and pops and it sounds pretty bad when it does.

I don't think people are regularly reporting this bug because hardly anyone has WAV files on their empegs.

The easiest way to reproduce this is to copy an entire album in WAV format, and listen to it end to end. Lots of skipping.

Calvin

yuck. so does this mean that any RTA tests i might attempt might be slightly skewed because of these pops and skips?

so does this mean that any RTA tests i might attempt might be slightly skewed because of these pops and skips?

Only if you're doing sweeps as opposed to full spectrum bursts, and only if you're depending on a "single pass" for the test (you shouldn't anyway).

When I do RTA, I have it looping a track constantly with continuous monitoring and updating. And by the way, I've never heard any of my short RTA test tracks skip. I don't usually keep long songs on the player for day to day listening, but I would imagine that if there were dropout problems they would probably only happen on long songs.

I've never defragged any of my ext2/3 partitions, never had the need. I did try a defrag utility once ages ago and it nuked the superblock which was fun.

There shouldn't be that much fragmentation on the empeg drives though unless you constantly add and remove music.

- Trevor

I don't think people are regularly reporting this bug because hardly anyone has WAV files on their empegs.

I have a fair number of .wav files in my player, and have never noticed any dropouts. Perhaps I just am not listening closely enough... but it seems like the sort of thing I would notice.

tanstaafl.

I get dropouts even with MP3s when doing searches, particularly if I type 2 or 3 characters ahead of the search utility narrowing down the list.

I also regularly see the visuals jitter as the empeg buffers data up from the hard drive, but I can live with that. The TextInfo visual makes it quite noticeable.

Thanks guys. Anyone know why waves won't play without droputs for some people? I guess it probably isn't from fragmentation. Even my iPAQ can play waves without dropouts. There must be a way. Perhaps turing off visuals?

Stu

I've never had any of these pause/dropout problems described in this thread.

Questions to those experiencing dropout problems...

1) Does your config.ini contain the entry that changes the amount of reserved cache memory on the player?

2) Are you running beta 13?

3) Have you replaced your init or are you running any other programs at startup other than the default player software?

4) How many tracks exist on your player?

I have only about 2000 tracks on my player and I'm not doing any of the above.

I have beta 13 plus Hijack 291 and about 1600 tracks. Don't know anything about the config.ini file. I certainly haven't changed it intentionally. I haven't replaced the init as far as I know.

Stu

1) Does your config.ini contain the entry that changes the amount of reserved cache memory on the player?

No

2) Are you running beta 13?

Yes. Hijack 291

3) Have you replaced your init or are you running any other programs at startup other than the default player software?

Yes I am using Bitt's preinit to start telnet, viewer and empacman, although I am sure it did it before I added them. I can remove them and let you know. The visuals definitely jittered on a clean unmodded player.

4) How many tracks exist on your player?

about 5100 on a single 30G disk.

Hmm, so then there's no commonality between you and Maczrool in those areas.

I've just never seen any dropouts or any jitter in my visuals, and I'm wondering why that would happen on your players and not mine.

I've mainly seen it using the search function although sometimes it seems something else is going on (another process or something) that causes a skip. Generally though it results from pressing a button or remote button.

I'm sure you use the search function right Tony? Do a title search and as quick as you can on the remote press 7 3 3 2 2 (should get you close to Red Barchetta ) and see what happens.

It could be that the fact you only have 2000 odd songs makes the search not show this problem.

Do a title search and as quick as you can on the remote press 7 3 3 2 2

On my system I have to press 7 8 7 4 7 3 3 2 2 (my title is: Rush-Red Barchetta) but when I do that I get no strange behavior.

Running 2.0b13, only one change to the init file (no de-dup when adding playlists), no HiJack.

tanstaafl.

The skips and such don't happen very frequently when searching, but do happen a lot while playing waves, even without searching. I only have three wave tracks and it does it at random places on all of them. They range from 3:47 to 5:40 in length.

Stu

It could be that the fact you only have 2000 odd songs makes the search not show this problem.

That is likely. I use the search often, and do not notice the problem you describe. I understand how a large list of titles might cause the problem (although I don't think they intended for there to be a problem in this case, it might need to be entered as an official bug).

It could be that the fact you only have 2000 odd songs makes the search not show this problem..

Yeah, but I was the one that brought this issue up and I only have 1600 tracks. It's not a big deal to me, because it doesn't happen much, but the WAV thing is too much.

Stu

1) Does your config.ini contain the entry that changes the amount of reserved cache memory on the player?

No

2) Are you running beta 13?

Yes

3) Have you replaced your init or are you running any other programs at startup other than the default player software?

It skips with the regular init and it skips with the init that runs other programs.

4) How many tracks exist on your player?

About 3500+.

I should note I *never* get skipping on mp3's, but WAVs will skip on average once every couple of songs.

Calvin

I have a 60 and a 20 gig unit and, I can recreate this problem on both units every time.

If i'm playing a wav file and pull the unit from the sled and then re-insert it, when the wav file resumes play, it plays for approx.30 sec. and then pauses play for approx 5 sec. and then resumes play.
Also, if i'm playing a mp3 file and them select a wav file , it will do the same thing every time, play the wav file for approx.30 sec. and then pauses play for approx 5 sec. and then resumes play.
I have had this problem with wav files with all versions of the software and have tried this with and without hijack installed.

So, is this a possible hardware problem?

My droputs aren't as long as yours. Mine are more like a 1/2 second long. Same duration whether searching or playing waves, but it happens a lot more frequently with wave files than with searching during playback. I'd say the waves do it 95% of the time every 3 minutes of play or so. I do have Hijack installed, but it did it before Hijack was installed too.

Stu

I get this comstantly on my 60gb player that has the largest collection on it (40gb). My other players have smaller collections of 20gb or less and I don't get that problem. I NEVER use WAV files on my player, so we're only talking about MP3's skipping while searching. It never has really bothered me much so I didn't think anything of it. I always thought that the HD just couldn't keep up with the demand I was laying on it. I can say that this is the reason I haven't upgraded to even larger storage on any of my players. I assume the issue will only get worse with larger drives and more music.

Tony,

I've never changed my config.ini file (at least that I know of)

I am running Beta 13, but it did it with Beta 11 also.

Not running any other programs on startup.

I have a bit over 10,000 tracks on my player (I've always figured this was the problem, see my previous thread).

"Running 2.0b13, only one change to the init file (no de-dup when adding playlists), no HiJack"

What is de-dup? I think I may have missed something usefull.

What is de-dup? I think I may have missed something usefull.

Look here, and be sure to read Roger's reply for some very good news indeed.

tanstaafl.

Hello everyone.

I have had similar problems with my 60GB player. I also have a 20GB player, but haven't had problems with it. Both players are Rio Mark2a running 2.13b/no Hijack. 60GB player has 4700 tracks, 20GB has 1000.

Yesterday I stumbled on a way to duplicate the wave pausing on a consistant basis.
Here's what to do:

Enable display of hard disk icon.
Set player display mode to Info/Track.
This will probably work best with a wave file that's 2min/20MB or longer.

1. Play the wave file.
2. At 2 seconds playtime, hit pause.
3. Wait untill the drive icon goes out completely.
4. Hit pause again to resume playing the track.

On my 60GB unit the following happens:
At 41 seconds of play, the "drives are spinning up" icon (empty center) appears. Track still plays normally.
At 43 seconds, a "W" appears next to the icon and the track halts.
Half a second to a second later the "W" disappears, the "data is being read" icon appears, and the track resumes playing.

On my 20GB unit the following happens:
At 46 seconds of play, the "drives are spinning up" icon (empty center) appears.
At 48 seconds, the "data is being read" icon appears.
There is no pause.

I tried several waves of different sizes and this happens every single time.

For those having the sound dropouts, can you try the above to see if you have similiar results?

Thanks for the tip. I'd like to try to duplicate your experience, but haven't a clue how to enable display of the hard disk icon. A search in the FAQ for "hard disk icon" yields nothing. Instructions?

Thanks,

Stu

It's under How do I know what the hard disk is doing?

In short: "Configure player" in emplode, check the box, sync

/Michael

At 43 seconds, a "W" appears next to the icon and the track halts.

Yes, the same thing happens to my player (30 GB with 1600 tracks), but at 42 seconds. The dropouts seem a little shorter in duration than the ones that occur without doing the pause at 2 seconds, but still it shouldn't happen.

Stu

A search in the FAQ for "hard disk icon" yields nothing.

Remember that the FAQ search is exact-phrase only. So the more words you put in the box, the less of a chance you'll find something.

A search on the single word "icon" will yield multiple responses, but at least it's fewer than ten responses and you can glean from the titles what the entry is about.

Bringing up the question again: Anyone have a good, simple, easy-to-plug-into-phpnuke fuzzy searcher?

I assume HTdig is out of the quesion?

I dunno, I remember that Tom researched this once and didn't come up with anything suitable right away. Dunno how much effort he put into finding something. I was just bringing up the question in hopes we could noodge him about it.

In reply to:

---

Yes, the same thing happens to my player (30 GB with 1600 tracks), but at 42 seconds. The dropouts seem a little shorter in duration than the ones that occur without doing the pause at 2 seconds, but still it shouldn't happen.

---

Right, it shouldn't. Is it possible that some drives take longer to spinup than the player software expects? I timed my 60GB with a stopwatch, and the total spinup time for both drives is roughly 3.75 to 4 seconds. 2 seconds per drive seems normal to me, but the "W" appears at beginning of the second drive's spinup. Does anyone know the max drive spinup time that the player expects? Is there any way to adjust this easily?

I did some searching through the forum posts and found some threads of similar problems here , here , here , here , and here .

Tony,
do you know if the problem mentioned in this thread was resolved in any post 2b11 release? I looked through the release notes for beta13, but none of the bugfixes listed seemed to relate to this particular issue.

do you know if the problem mentioned in this thread was resolved in any post 2b11 release? I looked through the release notes for beta13, but none of the bugfixes listed seemed to relate to this particular issue.

Correct, that is bug 1824 and it has not yet been marked as resolved in the internal bug list.

Correct, that is bug 1824 and it has not yet been marked as resolved in the internal bug list.

Thanks for checking.

It's not a fuzzy search, but it would be better than exact-phrase:

$searchArray=explode($searchString, ' ');

Then modify the SQL query to a WHERE with as many ANDs as there are words.

That's if it's being done as I would expect it is.

Aha, thanks. Back when I wrote the search code, I didn't know much about string manipulation. And I haven't had much time recently to revisit this. I will implement this soon though for the search. Hopefully tonight will be slow enough.