Hello,
I've just completed a server (empeg side) for empload /emptool clients. As suggested by someone in this forum, I wrote the server by sniffing ethernet packets (via Ethereal), studying the commands in client_protocol.cpp from emptool and implementing the required responses. It correctly sends and receives fids( tunes, playlists, config.ini, etc), rebuilds /empeg/var/database and /empeg/var/playlists files, sends back progress reports, and responds to all known commands. It is designed to be a companion to rioplay, enabling tune and playlist downloading. It's almost finished, but there are a couple of things that I don't understand...

When a new fid (say 0x320) is created, e.g. a new tune, three files are created:
320 -- the mp3 data file
321 -- a text file that contains the tags for the tune (e.g. title, bitrate, etc)
32f -- a 28 byte file with 7 integers 1,14,0,0,0,0,0

What is the purpose of the ??f file? The real empeg player app does not store the file in the /drive0/fid directory. It might be an entry for the dynamic database...


Next question
During the empload <-> empeg startup negotiation, empload requests the dynamic database. I just send a null file and empload doesn't seem to mind. But I believe the dynamic database contains information about when and how many times a song was played. Can someone tell me where I can read this data off my empeg and the format of the dynamic database? As far as I can tell, emptool does not use the dynamic database, so there is no source code for this.

Last question.
Is there an easy way to determine the last fid (actually the highest) on a drive? Is it wrong to include extra 0xff at the end of the database file?


Thanks,

-Scott

In protocolclient.cpp, look at

STATUS ProtocolClient::RetrieveDatabases(TuneDatabaseObserver *db_observer)

specifically the references to dynamic_buffer (which is of type dynamic_data)

I'd tell you to look at the jEmplode source too, but I believe there are some problems in my port of the dynamic data code

ms

The real empeg player app does not store the file in the /drive0/fid directory. It might be an entry for the dynamic database...

Indeed. The stock player spots those "special" (*F) fids, and writes to the dynamic database instead of the filesystem.

But I believe the dynamic database contains information about when and how many times a song was played. Can someone tell me where I can read this data off my empeg and the format of the dynamic database?

The dynamic database lives on the scratch partition. We've never given out the layout of the scratch partition (so that we could change it behind the scenes if we wanted -- it's bad enough that we're stuck with that static database format now everyone reads/writes it) but having got this far it shouldn't be hard for you to reverse-engineer it. The scratch partition layout will not change for 2.0 final, but it's not ideal and so might well change in some post-2.0 release.

Is there an easy way to determine the last fid (actually the highest) on a drive?

No. Currently you must readdir() both fid directories.

Is it wrong to include extra 0xff at the end of the database file?

Nothing will break, but you'd be wasting valuable player memory (and marginally decreasing search speed).

Peter

I'm a little confused at the idea behind this empeg-side server. Would this be a web/java version of (j)emplode that resides on the empeg instead of having to install (j)emplode on multiople pc's?

If not, could you please give an explination about the purpose/application of this server?

AOL

No.

It is designed as a replacement for part of the player software. The bit it replaces is the bit that (j)emplode talks to when managing the database.

The end aim being to not have to run the player software at all.

The reasons for wanting to do this is so that you can end up with a complete open source replacement for the player software and therefore add new features (such as OGG) without waiting for Hugo, Rob, Peter, Roger, Toby et al

That's how I understand it anyway.

Race?

Ooooohhh!

Race?

Ooh, ooh, competition is good! Maybe now we'll get some of those "not yet backported" features onto our beloved empegs!

In reply to:

---

Race?

---

Now thats what I like to hear

Can't wait for 2.0 final and beyond.

I've got $5 on the new guy.

I've got $5 on the new guy.

Given the historical precedent, I'll take the other side of that one.

Many have tried, and once everyone sees how tough it is to actually make these things happen, they realize waiting for the empeg guys to do it (despite how often their priorities don't give them much car player time) is the best way to go.

In fact this thread hasn't changed anything. Plans have been afoot for a while. The alpha team are blowing cobwebs from their serial ports as I speak.

Rob

So, I assume you're still not looking for bribes from or to new alpha testers?

Rob, I've been meaning to ask this for awhile. What the hell is the need for an "alpha team" nowadays when the product is now EOL? I get the feeling that there are features that have been "in the can" for months and years now that are held back because they haven't been fully tested. Are our empegs controlling missiles or space shuttles? I understand that the point of solid testing procedure is to get release-quality code so that consumers don't call in with stupid questions because they're running beta versions. But empeg users have been running beta versions *forever* and really, we're used to a few quirky things not working.

Like last year some time, I can't remember if it was 2.0b7, b11, or b13, but one of those.... Some stupid USB bug held up the entire release for god-knows-how-long. I use Ethernet, and couldn't give a damn about USB. Why couldn't it just be released with the caveat "if you run USB, you may experience problems."

I guess I just don't see the point anymore in holding these things back from release now that the product has been discontinued, and isn't going to be a mass-market product. Since we're kinda just a branch hanging off of the tree now (with the other current Rio products being at the trunk) why can't we get exprimental stuff without the hassle of a big test cycle to slow progress down even more? We already pay the penalty of having to wait for a back-port, and now we need to let the alpha team hang onto it for even longer?

I think the whole alpha test phase made sense back in the day, but nowadays, I just wish we could abandon the alpha and just go to wide beta testing, with maybe quarterly releases instead of yearly ones. Those who "can't stand the heat" of running the new version can go back to their last-known-good. Simple, yes?

I couldn't agree more, where I work we pay our testers A LOT, they aren't very tech savy and basically document steps to break the software. I'm assuming you pay your testers.... why not save SB some money and give it to us to test for free.

The alpha team get a release for a few days before you get it, assuming it works out OK. We want a few focussed reports and discussions of bugs in a new drop, not 3000 people all jumping in at once. They also have direct access to the bug database, which is not about to become available to the world at large.

The team may also get to play with features that we have no intention of releasing widely yet. They're under NDA, you're not

In practice the team haven't had anything since Beta 13 - until tonight.

Rob

The alpha team are all customer volunteers. An EOL product doesn't get to use extremely expensive QA resources, so the effort put in by the alpha team is much appreciated.

I'm assuming you pay your testers.... why not save SB some money and give it to us to test for free.

No, the alpha testers are not paid. They are just a sub-set of the bbs people who get things that are a bit buggier than the normal beta releases.

There have been alpha releases you would *not* have wanted -- one of them actually killed all of the songs on the player. I think Tony Fabris and... who was it? N6Mod? got nailed by that one.

Not all of the bugs fixed by the alpha team are benign annoyances. There are really good reasons that the guys@empeg alpha test this stuff before releasing it to to the general population of the bbs.

tanstaafl.

Ah.... I see.... Need anymore alpha testers?

I'd sign an NDA. Just send it over... It's not like this one would at all interfere with my work in distributed filesystems, or authentication

I think this is one of those "Don't call us, we'll call you" type things

Yeah, probably, but a man's got to try. I don't even know if they have my number

I'd sign an NDA too....

I think this is one of those "someone has to die before someone new can join" things. That's why we don't publish a list of team members

Rob

In practice the team haven't had anything since Beta 13 - until tonight.

Well, I'm glad to hear that. We'll see how things work out this time. I've just been hoping that as the necessity for SonicBlue to officially be involved in the empeg car product diminishes, we'd start seeing more frequent and less "officially blessed" and rigorously-tested releases. It's not that I don't want quality code, it's more that I think that some of the best innovations on the player were things that were kinda thrown in and initially had bugs in them (the seek tool comes to mind.)

I just hope we don't have to wait another six months between releases, and I thought a change in philosophy and focus might be appropriate now that the product doesn't need to officially be supported as much anymore.

Yeah. If there is some disasterous problem with the alpha build then you'll only have a few people needing help to get it fixed. Having 2000-3000 people all complaining about how it nuked their entire player wouldn't be too great!

- Trevor

The alpha team wasn't SB's idea, it was an empeg creation. The car player software strategy has always been in the hands of the Cambridge team, and we can release what we want when we want - as long as the official projects also get done. Since taking over all of Audio for SB we have a lot of official projects right now.

Anyway, in a few days I'll release some information and you'll be able to see why the 2.0 milestone had effectively stagnated car player development, and why getting past that to 3.0 betas is going to help plenty. You might just get that horribly unreliable firmware you crave a little sooner than you realise

Rob

What do I care if it nukes my whole player? That's why I have a spare, an extra just to break again and again. Just use that for testing for a while, carry my "real" empeg with me so if it becomes unusable due to testing I can still listen, and move right along with life.

I know that the alpha team has been around since the beginning. I would just much rather have the features out there earlier in more peoples' hands. If you can't handle the bugs, or are stupid enough to nuke your player and not have a backup, you'll be less likely to use the newer builds. In my experience, a small "alpha" team doesn't do nearly as much as a larger "wide beta" approach.