For any V3 alpha covetors, I can say that all of those alpha disclaimers are worth the time it takes to read them. Ah, you see, Jim's Empeg #1, "Hugo", is now NO WORKY. le musica es DESPARACIDO.

In essence, the Empeg seems to work until you attempt to play more tnan one song. YES, I -- THE STUPID BOY -- decided to use V3 Emplode to move a few treasured OGGs on to the Empeg...and then all of the problems begin

A coincidental bad cable? Well, I have jiggled every cable within reach, and I see no cable-related evil messages in my boot logs.... FSCK? Well, I have FSCK the disks until the FAQs run out of laser toner! All I have left now is the dark, mysterious "Error 19" .... I have asked Mister Reiser about this, but no answer yet.

So, Am I suffereing from stupidity? What is it that I am missing in this log???


empeg-car bootstrap v1.02 20001106 (hugo@empeg.com)
If there is anyone present who wants to upgrade the flash, let them speak now,
or forever hold their peace...it seems not. Let fly the Penguins of Linux!

e000 v1.04
Copying kernel...
Calling linux kernel...
Uncompressing Linux..................................... done, booting the kerne
l.
Linux version 2.2.14-rmk5-np17-empeg52 (rob@aphex) (gcc version 2.95.3 20010315
(release)) #11 Tue Apr 1 18:49:59 BST 2003
Processor: Intel StrongARM-1100 revision 11
NetWinder Floating Point Emulator V0.94.1 (c) 1998 Corel Computer Corp.
empeg-car player (hardware revision 9, serial number 10102052)
Command line: mem=16m
Calibrating delay loop... 207.67 BogoMIPS
Memory: 15024k/16M available (964k code, 20k reserved, 372k data, 4k init)
Dentry hash table entries: 2048 (order 2, 16k)
Buffer cache hash table entries: 16384 (order 4, 64k)
Page cache hash table entries: 4096 (order 2, 16k)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
TCP: Hash tables configured (ehash 16384 bhash 16384)
IrDA (tm) Protocols for Linux-2.2 (Dag Brattli)
Linux-IrDA: IrCOMM protocol ( revision:Tue May 18 03:11:39 1999 )
ircomm_tty: virtual tty driver for IrCOMM ( revision:Wed May 26 00:49:11 1999 )
Starting kswapd v 1.5
SA1100 serial driver version 4.27 with no serial options enabled
ttyS00 at 0xf8010000 (irq = 15) is a SA1100 UART
ttyS01 at 0xf8050000 (irq = 17) is a SA1100 UART
ttyS02 at 0xf8030000 (irq = 16) is a SA1100 UART
Signature is 206f6972 'rio '
empeg display initialised.
empeg dsp audio initialised
empeg dsp mixer initialised
empeg dsp initialised
empeg audio-in initialised, CS4231A revision a0
empeg remote control/panel button initialised.
empeg usb initialised, PDIUSBD12 id 1012
empeg state support initialised 0089/88c1 (save to d0005180).
empeg RDS driver initialised
empeg power-pic driver initialised (first boot)
RAM disk driver initialized: 16 RAM disks of 4096K size
empeg single channel IDE
Probing primary interface...
hda: IBM-DJSA-230, ATA DISK drive
hdb: IBM-DJSA-230, ATA DISK drive
ide0 at 0x000-0x007,0x038 on irq 6
hda: IBM-DJSA-230, 28615MB w/1874kB Cache, CHS=58140/16/63
hdb: IBM-DJSA-230, 28615MB w/1874kB Cache, CHS=58140/16/63
empeg-flash driver initialized
smc chip id/revision 0x3349
smc9194.c:v0.12 03/06/96 by Erik Stahlman (erik@vt.edu)

SMC9194: SMC91C94(r:9) at 0x4008000 IRQ:7 INTF:TP MEM:6144b MAC 00:02:d7:22:08:0
4
Partition check:
hda: hda1 < hda5 hda6 > hda2 hda3 hda4
hdb: hdb1 < hdb5 hdb6 > hdb2 hdb3 hdb4
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 320 blocks [1 disk] into ram disk... done.
VFS: Mounted root (ext2 filesystem).
empeg-pump v0.03 (19980601)
Press Ctrl-A to enter pump...VFS: Mounted root (ext2 filesystem) readonly.
change_root: old root has d_count=1
Trying to unmount old root ... okay
Freeing unused kernel memory: 4k initempeg init 0.8
I see this is a developer image!
Mounting proc
Mounting first music partition
Tried to mount /dev/hda4 as reiserfs but got error 19
Mounting second music partition
Remounting first music partition read-only
Remounting second music partition read-only
Press 'q' now to go into development mode. You Have Zero Seconds To Comply...
Starting player
player.cpp : 385:empeg-car 2.00 2003/04/01.
Prolux 4 empeg car - 2.1434 Mar 26 2003
Vcb: 0x4086d000


Anyhow.....the Empeg boots, works, and allows synchs from Emplode *once*, but then freezes up and Emplode will crash if synch attempted again....

All of this notwithstanding, I still think that it is VERY COOL that V3 lives!

(edit: Oh and, yes, I downgraded to V2 for the purposes of troubleshooting. I just haven't run the bulider image yet!!!)

That bot log looks normal to me (after a quick scan)...

The reiser fs error 19 is perfectly normal - there's an attempt to mount the filesystem as a reiser fs, but since it is an ext2 filesystem, it of course fails (don't recall exactly why it tries the reiser fs, but it is normal)

/Michael

(don't recall exactly why it tries the reiser fs, but it is normal)

Because it's the same code that runs on Jupiter (Rio Central), where it would find a Reiser partition.

Peter

My guess would be that your database is hosed. Try following the instructions to dlete the database found in this FAQ and then resync with emplode. You might also want to try JEmplode at this point (possibly after deleting the database again), as I seem to remember that it handles unknown file types a little better than emplode (but I might not be remembering correctly on this one).

Caveat lector: I've not done the database delete thing, and I don't quite remember if it has effects beyond simply cleaning out the database to be rebuilt. I don't think it does, but I could well be wrong.

My guess would be that your database is hosed. Try following the instructions to dlete the database found in this FAQ and then resync with emplode.

Yes, that's what I figured. Curiously, I went through that db/tag/playlist delete routine once yesterday and again this AM, and, in each case, when I run Emplode after the fact my playlists are still there (not what i expected after deleting /drive0/var/playlists!.....hmmmm, if this is normal I guess that means that the DBs/playlists are rebuilt from FIDs?)

(the fact that /drive1/var/* weren't found I chalked up to this player not having enough music to fill more than the 1st drive....)

You might also want to try JEmplode at this point (possibly after deleting the database again), as I seem to remember that it handles unknown file types a little better than emplode (but I might not be remembering correctly on this one).

Now that I hadn't considered....and I do have some "unknown" OGG files on the player now that v2 player/Emplode would not recognize...

Caveat lector: I've not done the database delete thing, and I don't quite remember if it has effects beyond simply cleaning out the database to be rebuilt. I don't think it does, but I could well be wrong.

Well, I'm way beyond caveats now! Anything short of a builder install I would consider a win. Hmmm, I may pop a spare laptop drive in this unit and run builder just to make sure I don't have a coincidental hardware problem. As it stands now, the symptoms are that the player starts normally, and menus may operate normally for a bit, but the player and display lock up after 1 song or any attempt to change the song/playlist. Certainly sounds like a DB problem.

Oh, the Pollyanna side of this? VMWare rocks. I used the "official" Empeg upgrade tool and was able to use that and Hyperterm under VMWare -- both were talking to "COM3" on a Comtrol Rocketport 8Si IP terminal server. The Comtrol Windows drivers seem to work just swell with the VMWare virtual IP.

(This is really good news as I have a bunch of infrequently used Windows utilities such as for Icom+Kenwood radio programming that require a COM port but which I don't want to reboot for)

What's your host OS, there, Jim? (BTW, I've used VMWare as long ago as, I think, four years, and it rocked then.)

I do have some "unknown" OGG files on the player now that v2 player/Emplode would not recognize.

Exactly, and I didn't say it, so my advice would be to delete those files ASAP and then try rebuilding the database again.

the fact that /drive1/var/* weren't found I chalked up to this player not having enough music to fill more than the 1st drive

That may not be the case. See this FAQ.

What's your host OS, there, Jim?

Running Redhat 9 dual-boot with Win2K, but I pretty much kept native Win2K for some video tools that I do not use frequently. I run Win2K under VMWare and have my /home Samba mounted so that I can mount it from the virtual machine. Likewise, although I don't use a browser much in the VM, it is pointed at the proivoxy/squid proxy on the host machine.

FWIW, I sprang for the recent VMWare 4 upgrade and feel like I got my $100 worth. Lots of small things seem better. I tend to park VMWare on a designated "Windows" desktop and leave it running, so I may have to succumb to the temptation to add another 512MB stick of RAM...

That may not be the case.

A ha! And that is the case. Lots of FIDs on /drive1, just nothing in var.

My playlists are sooooo simple, I am tempted to start fresh, let the builder clean house.

just nothing in var

Ah, I misread your earlier post. To clarify: You'd expect to find nothing in /drive1/var, regardless of the content on the disk. You might see files in here if you've added another disk, and this disk was previously the primary.

Files in /drive1/var should be harmless, but there have been reports of oddness. Delete them if you're feeling paranoid.

The database and playlists are stored in /drive0/var, and can be completely rebuilt from the data in the *1 files stored in the 'fids' directories.

The music is kept in /drive0/fids and /drive1/fids and is distributed as described in that FAQ entry.

Jim, after deleting the database/tags/playlists files off the player, you must re-synch with emplode once to get it to rebuild them properly.

It'll rebuild them on-the-fly each boot, but they won't get written to the hard disk unless you synch with emplode.

If you're having trouble with doing that with emplode 3.0, it is safe to go back to emplode 2.0 and use that.

Can't you just set the drives as read/write and run the player application from command line? That always works for me.

Can't you just set the drives as read/write and run the player application from command line? That always works for me.

Yeessss, but we don't tell people that because of the risk of them corrupting their filesystems by not rerunning the player before powering off. Manually remounting the filesystems read-write is one of the traditional borderlines between a consumer-level tech-supportable situation and a geek-level you're-on-your-own situation...

That's why the FAQ (last I looked) still tells people to use Emplode/Emptool to fix the database: so that nothing except our own software ever sees a read-write mounted filesystem.

Peter

Jim, after deleting the database/tags/playlists files off the player, you must re-synch with emplode once to get it to rebuild them properly....

....If you're having trouble with doing that with emplode 3.0, it is safe to go back to emplode 2.0 and use that.

I followed enough of the fabulous FAQs to cover these angles so far, and I reverted everything to V2 about a day and a half ago. The emplode on the CD just kept abeninding when I tried post-DB-delete resynchs so I went back to V2. The one thing I haven't tried is jEmplode synching as, for some reason that I won't recognize until I've had some lunch, my JRE seems hosed up....

I may momentarily cease to perseverate and go the builder route, unless there is any communal diagnostic value in more persistent perseveration. One good Jim side-effect is that I have learned a few things about the Empeg that I should have learned long ago!

Hahahaha. Valid point. A sign "abandon all hope ye who enter here".

That's why the FAQ (last I looked) still tells people to use Emplode/Emptool to fix the database:

Um, actually, it's not in the FAQ because I hadn't thought of it. Paul's mention is the first I'd heard of it.

So what would be the correct commands for doing it that way?

Let's see, I was thinking of editing that FAQ entry a bit anyway, so how's this for a proposed rewrite:

You should be at a shell prompt now. Enter:

rwm (There will be a long pause)
rm /drive0/var/database
rm /drive0/var/database3
rm /drive0/var/tags
rm /drive0/var/playlists
rm /drive1/var/database
rm /drive1/var/database3
rm /drive1/var/tags
rm /drive1/var/playlists
(Note that some of those RM commands will not work, that's OK)
/empeg/bin/player
(The player application will run and rebuild the databases)
q
(This should exit the player application back to the shell prompt)
rom
exit

Is that the correct procedure? Should that work?

Is that the correct procedure? Should that work?

It's not the correct procedure, and it's not likely to work. That's a good example of why I'd prefer this player feature wasn't mentioned in the FAQ, because it'd only encourage people to make stuff up which won't work.

(The problem is that you shouldn't run the player from the shell, as that'll use up too much memory, especially if the player is rebuilding the databases; you should use exec to replace the shell with the player, or just ^D the shell. But I stand by the suggestion that the FAQ shouldn't mention any database rebuild method except doing a full synchronise.)

Peter

The problem is that you shouldn't run the player from the shell, as that'll use up too much memory

Okay, what if I did EXIT instead of /empeg/bin/player ?

edit: tried it, it seemed to work... Thanks for the warning about memory...

Well, not good...

Basically, if you set to read/write and exit, you will mark the filesystems as dirty and force and fsck. Highly annoying.

While it may not be the right way to do it, I have gone to shell, rwm'ed the music partitions, deleted the database files and run the player app from command line. I have not had it fail on me with either Mark2 or Mark2a players. Granted, if you have additional software in the background, it might cause memory problems.

One trivia note - when you q out of the player application run from command line, it is very graceful and sets the filesystems back to read only. So, if you were planning on doing additional work, you need to rwm them again...

Edit: I do this all the time keeping the players in sync with rsync. After the rsync completes, I used to run the player app while read/write, quit out, set the filesystems read/write again and then run swapon and mirrordb (symlink tree builder). Now, though, I am too lazy and just rsync the database files too...

Basically, if you set to read/write and exit, you will mark the filesystems as dirty and force and fsck. Highly annoying.

I just tried it, and I didn't get the dirty filesystem problem. It didn't complain about needing to FSCK, even after a power cycle and going back to the shell and RWM'ing again.

...

Wow! I could have sworn that marked them as dirty. Did you do a "sync" command or do any filesystem work between the rwm and the exit? That might be it.

In any case, a big disclaimer of "Don't try this at home" would be appropriate. I conceed the point - this is not for anyone who is unfamiliar with unix, or would mind blowing their filesystems to billions of random bits.

Did you do a "sync" command or do any filesystem work between the rwm and the exit?

No, I didn't. I did the commands as I listed above in the thread, except I replaced "/empeg/bin/player" with "exit", and it all seemed to work.

Of course, I wasn't having disk trouble when I did it. I'm guessing people who are having trouble with their databases might also be having disk trouble, so I should beef up the FAQ entry regarding FSCKing before you do this.

I conceed the point - this is not for anyone who is unfamiliar with unix, or would mind blowing their filesystems to billions of random bits.

While I also concede Peter's point, I have the following philosophy regarding this:

- Synching once with emplode should have taken care of it in the first place.

- If that didn't work, we're already in "problem" territory and we need to get this dealt with.

- We're already telling them to RWM the drives and delete files. From there, it's not a big step to exit the shell and have the player app fire off a database rebuild.

- Some people have reported getting Emplode working to synch when they're having these kinds of problems. In fact, these kinds of problems might be caused by problems with emplode. So if they need to do this procedure at all, it's actually better if we can leave emplode out of the equation.

Does anyone have any other warnings with regard to doing it that way?

If that didn't work, we're already in "problem" territory and we need to get this dealt with.

And, as I remember, that's the exact situation where that FAQ was added. Emplode syncing didn't work, but that procedure did.

If you're having trouble with doing that with emplode 3.0, it is safe to go back to emplode 2.0 and use that.


In my experience, it is not only safe, but mandatory.

YMMV.

tanstaafl.