Unoffical empeg BBS

Quick Links: Empeg FAQ | RioCar.Org | Hijack | BigDisk Builder | jEmplode | emphatic
Repairs: Repairs

Page 3 of 4 < 1 2 3 4 >
Topic Options
#139961 - 08/02/2003 10:17 Re: Current playlist and order [Re: peter]
pgrzelak
carpal tunnel

Registered: 15/08/2000
Posts: 4859
Loc: New Jersey, USA
Greetings!

You rang?

Still no word on the 80s yet...
_________________________
Paul Grzelak
200GB with 48MB RAM, Illuminated Buttons and Digital Outputs

Top
#139962 - 08/02/2003 12:21 Re: Current playlist and order [Re: peter]
Daria
carpal tunnel

Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
This means that if you've got more than 10,901 tracks on your player (which is not at all out of the question for a grzelakian, sorry gargantuan, player)

I have an 80gb player that's not even full with more tracks than that.

Top
#139963 - 09/02/2003 12:15 Re: Current playlist and order [Re: peter]
jaharkes
enthusiast

Registered: 20/08/2002
Posts: 340
Loc: Pittsburgh, PA
And I always thought that playlists worked like a typical jukebox. When several people choose the same song, it will only be played once. Of course the jukebox won't tell you this and still keep your money.

So when I insert an album into my 'play everything' playlist, or use the 'same artist' thingy on the remote, it won't pull those songs out of the regular running order?
_________________________
40GB - serial #40104051 gpsapp

Top
#139964 - 09/02/2003 12:26 Re: Current playlist and order [Re: jaharkes]
johnmcd3
enthusiast

Registered: 19/04/2001
Posts: 369
Loc: Seattle, WA (formerly Houston,...
So when I insert an album into my 'play everything' playlist, or use the 'same artist' thingy on the remote, it won't pull those songs out of the regular running order?

No, I believe it leaves the rest of the playlist untouched.

But Peter was also refering to the fact that most people's playlists that reference the same song from different playlists, like a classical playlist and a mellow playlist would likely overlap to some extent.
_________________________
1998 BMW ///M3 30 GB Mk2a, Tuner, and 10 GB backup

Top
#139965 - 09/02/2003 12:54 Re: Current playlist and order [Re: jaharkes]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4172
Loc: Cambridge, England
So when I insert an album into my 'play everything' playlist, or use the 'same artist' thingy on the remote, it won't pull those songs out of the regular running order?

When you insert an album (whether from the search screen or the playlists menu), those tracks are added to the playlist, even if they were there already (even in shuffle mode). When you use the same artist thingy on the remote, those songs are swapped into position from wherever they are in the playlist -- it won't find songs by the same artist that aren't in the current playlist.

Peter

Top
#139966 - 11/02/2003 11:48 Re: Current playlist and order [Re: peter]
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
Peter, can you clue me in as to where I might look to get the current running order position, and the total number of tracks in the current running order? Like, when the Track:Info screen says:

[310/6521]

Are these values only in memory or are they in the flash savearea? Or somewhere else where one can read them?
_________________________
- Tony C
my empeg stuff

Top
#139967 - 11/02/2003 13:49 Re: Current playlist and order [Re: tonyc]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
Current position is in the flash savearea, stored as a 32-bit FID. Dunno about position within that FID.

-ml

Top
#139968 - 11/02/2003 16:51 Re: Current playlist and order [Re: mlord]
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
Anyone else have any ideas?
_________________________
- Tony C
my empeg stuff

Top
#139969 - 11/02/2003 17:29 Re: Current playlist and order [Re: tonyc]
genixia
Carpal Tunnel

Registered: 08/02/2002
Posts: 3411
Current position has to be stored somewhere. I was wondering if maybe the current Fid was used to index the running order, but I realised that would 'fail' on duplicates. However, I also remembered that duplicates are quirky anyway - they always get removed during shuffle, and re-inserted during unshuffle, so I checked...

If you have 1 track duplicated in a playlist, and the player is playing one of them at the point of shutdown, it will continue to play the correct one after power up.

The search continues...
_________________________
Mk2a 60GB Blue. Serial 030102962 sig.mp3: File Format not Valid.

Top
#139970 - 11/02/2003 17:33 Re: Current playlist and order [Re: genixia]
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
And how about total length of the running order? That has to be stored somewhere too, unless the player counts them every time it boots up...

Edit: Length = number of songs, in this context.
_________________________
- Tony C
my empeg stuff

Top
#139971 - 11/02/2003 18:16 Re: Current playlist and order [Re: tonyc]
genixia
Carpal Tunnel

Registered: 08/02/2002
Posts: 3411
Hmm...that depends. If the player keeps the whole running list in memory then it'd be trivial to either count each entry during load, or if being loaded as an array, to do a sizeof() and do the math after loading.

But if the player only loads as much of the running list as it needs then it would need to be stored.

I suspect that since the entire database is kept in memory then the whole running list is too.

_________________________
Mk2a 60GB Blue. Serial 030102962 sig.mp3: File Format not Valid.

Top
#139972 - 12/02/2003 03:28 Re: Current playlist and order [Re: tonyc]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4172
Loc: Cambridge, England
Peter, can you clue me in as to where I might look to get the current running order position, and the total number of tracks in the current running order? Like, when the Track:Info screen says:

[310/6521]

Are these values only in memory or are they in the flash savearea? Or somewhere else where one can read them?


The first sector of each stored running-order (i.e. sector 0 for the current running order and sectors 512, 1024, and 1536 for the three bookmarks) contains a header structure that includes, among other things, the sizes of the programme and running order, the repeat mode, and the FID of the playlist used to form the current running order (or 0 if it's "custom" i.e. was made from search results or if inserts or appends were done to it).

The header also contains a running-order index and a timecode in centiseconds -- but these are only used for bookmarks; the running-order index and timecode for the current running order are stored to flash, not disk (so they can be written with the last dying milliamps if the player is yanked).

Mark's observation, that sector 0 contains a partial copy of the programme and/or running order, is due only to buffer reuse and is not significant.

The usual caveat applies: that all this will pass, like rain on the mountain, like a wind in the meadow, after 2.0final comes out.

Peter

Top
#139973 - 12/02/2003 05:46 Re: Current playlist and order [Re: peter]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31563
Loc: Seattle, WA
This sounds like information that the The "Developer Info" gnomes should be collecting and re-posting...
_________________________
Tony Fabris

Top
#139974 - 12/02/2003 07:55 Re: Current playlist and order [Re: peter]
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
The first sector of each stored running-order (i.e. sector 0 for the current running order and sectors 512, 1024, and 1536 for the three bookmarks) contains a header structure that includes, among other things, the sizes of the programme and running order, the repeat mode, and the FID of the playlist used to form the current running order (or 0 if it's "custom" i.e. was made from search results or if inserts or appends were done to it).

I don't suppose that header structure is in a .h file somewhere like the other dynamic data stuff is? (Just so you know, I really do plan on using this stuff, I'm not just asking out of idle curiosity.) I can possibly reverse-engineer portions of it, but if it was in emptool somewhere or you had it handy, that'd be of great help to what I'm doing.

The usual caveat applies: that all this will pass, like rain on the mountain, like a wind in the meadow, after 2.0final comes out.

That's fine, I'll be happy to bug you again for the new format when that happens. Semantic question, though... Does "after 2.0 final comes out" mean that 2.0 final will have a different format, or that the future releases beyond 2.0 will have a different format?
_________________________
- Tony C
my empeg stuff

Top
#139975 - 12/02/2003 07:57 Re: Current playlist and order [Re: tfabris]
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
This sounds like information that the The "Developer Info" gnomes should be collecting and re-posting...

Well it sounds like the shelf life of this info might not be all that long... I'm going to hold off on posting this one until I can figure out some more details of what the bits and bytes all mean.
_________________________
- Tony C
my empeg stuff

Top
#139976 - 12/02/2003 08:10 Re: Current playlist and order [Re: tonyc]
Roger
carpal tunnel

Registered: 18/01/2000
Posts: 5680
Loc: London, UK
Does "after 2.0 final comes out" mean that 2.0 final will have a different format, or that the future releases beyond 2.0 will have a different format?

2.0 final will be the last release with this format. Releases beyond 2.0 will probably have a different format.
_________________________
-- roger

Top
#139977 - 12/02/2003 08:23 Re: Current playlist and order [Re: tonyc]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4172
Loc: Cambridge, England
Does "after 2.0 final comes out" mean that 2.0 final will have a different format, or that the future releases beyond 2.0 will have a different format?

2.0final will have the same format, unless some sudden and desparate bug requires that we change it, which is very unlikely. The format isn't in an emptool source release, but it shouldn't be too hard to work out, at least for reading. There isn't even a CRC.

Peter

Top
#139978 - 12/02/2003 08:26 Re: Current playlist and order [Re: peter]
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
The format isn't in an emptool source release, but it shouldn't be too hard to work out, at least for reading. There isn't even a CRC.

Thanks guys, at least I know where to look now, I shouldn't have any problems deciphering it.
_________________________
- Tony C
my empeg stuff

Top
#139979 - 12/02/2003 08:34 Re: Current playlist and order [Re: tonyc]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
Go for it, Tony!

But we must all be careful not to be disappointed a year from now when we may be playing with v3-beta player software, and discover that (1) the format is entirely different, and (2) they (peter) cannot tell us anything about the new layout. I fully expect this to be the case, as the data layout on disk is one of the "tricks" they will have evolved, and will not want to share with any competitors.

So, by all means, we should take advantage of any knowledge of the current layout, and just plan on having to do it "the hard way" when it all gets pulled out from under us.

Cheers!

Top
#139980 - 12/02/2003 08:43 Re: Current playlist and order [Re: mlord]
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
I fully expect this to be the case, as the data layout on disk is one of the "tricks" they will have evolved, and will not want to share with any competitors.

You really think that's the case? I'm not sure that on an EOL product, the layout of particular bits of information is all that much of a trade secret. I could be wrong, maybe they're sharing the same data structures with other living products... But I've found that, while the guys aren't spending their time advertising the formats or publishing them, they've been very helpful in casually pointing at a given area and saying "reverse engineer away, young man."

So, by all means, we should take advantage of any knowledge of the current layout, and just plan on having to do it "the hard way" when it all gets pulled out from under us.

Fellas, is Mark correct? Do you anticipate having to be more guarded about stuff like this in the v3 timeframe due to similarity to other products?
_________________________
- Tony C
my empeg stuff

Top
#139981 - 12/02/2003 08:54 Re: Current playlist and order [Re: tonyc]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4172
Loc: Cambridge, England
Fellas, is Mark correct? Do you anticipate having to be more guarded about stuff like this in the v3 timeframe due to similarity to other products?

The running order can be used to work out which songs you've listened to and which you haven't. Legally, that information is the copyright property of the record company.

No, actually I'm kidding. There are some specific things we feel nervous about helping people reverse-engineer, and I'm not going to be drawn on what they are, but hitherto this certainly hasn't been one of them.

Peter

Top
#139982 - 12/02/2003 09:03 Re: Current playlist and order [Re: peter]
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
No, actually I'm kidding. There are some specific things we feel nervous about helping people reverse-engineer, and I'm not going to be drawn on what they are, but hitherto this certainly hasn't been one of them.

Huzzah!
_________________________
- Tony C
my empeg stuff

Top
#139983 - 12/02/2003 10:04 Re: Current playlist and order [Re: peter]
Daria
carpal tunnel

Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
There are some specific things we feel nervous about helping people reverse-engineer

<cough>tuner settings</cough>

Top
#139984 - 12/02/2003 10:21 Re: Current playlist and order [Re: Daria]
tman
carpal tunnel

Registered: 24/12/2001
Posts: 5528
I'd guess it would be stuff about the serial number and other things. <paranoia>Or the secret mind control system that makes you want to go out and buy more empeg/SB stuff...</paranoia>

- Trevor

Top
#139985 - 12/02/2003 19:45 Re: Current playlist and order [Re: mlord]
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
Go for it, Tony!

I got it!

I haven't worked out all the fields of the header in the first sector of hda3, but I found the fields I care about for my purposes. Here's what I've got (duplicating your previous information just for clarity)


0x0010: playlist size (PS)
0x0018: running order size (ROS)
0x0200: beginning of FIDs in the playlist, 8 bytes each
0x0200 + 8 * (PS): beginning of the running order indexes, 4 bytes each

.
The ROS is only different than the PS if you've shuffled (due to duplicate removal.)

So with the above information, given an index into the current running order, I can find the FID number associated with that index. That's not very interesting for the currently playing FID, because we can get that from many areas, including the flash savearea and /proc/empeg_notify. BUT.. Cobbling this information together allows me to get the NEXT fid that will play in the current running order. If I'm at index N of the running order, I just need to go to index N+1, follow that as an index into the FIDs area at 0x200, and there we have it. I wrote a tiny C program to convert a running order index into a FID and it is working flawlessly. Righteous!

Now all I need is a way to get where we're at within the current running order from the userland... It's in the flash savearea, but there's no ioctl() for that. If there was, well, my master plan is going to start coming together very nicely.

Sweet, now I can finally go back to working on my school projects...
_________________________
- Tony C
my empeg stuff

Top
#139986 - 12/02/2003 21:45 Re: Current playlist and order [Re: tonyc]
Daria
carpal tunnel

Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
Now all I need is a way to get where we're at within the current running order from the userland... It's in the flash savearea, but there's no ioctl() for that. If there was, well, my master plan is going to start coming together very nicely.


I guess if Mark doesn't do something I'll write a patch.

Top
#139987 - 12/02/2003 21:48 Hijack v314: open("/dev/empeg_state",O_RDONLY) [Re: Daria]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
The savearea is readable from /dev/empeg_state. The stock kernel doesn't allow multiple readers in there at once though, so Hijack v314 will be out shortly with that capability added.

Cheers

Top
#139988 - 12/02/2003 21:50 Re: Hijack v314: open("/dev/empeg_state",O_RDONLY) [Re: mlord]
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
Woohoo!
_________________________
- Tony C
my empeg stuff

Top
#139989 - 12/02/2003 21:55 Re: Hijack v314: open("/dev/empeg_state",O_RDONLY) [Re: mlord]
Daria
carpal tunnel

Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
Ok, so I'll find something more useful to do.

I sent a patch to Jan for gpsapp which implements real time display of NMEA strings, but I'm not overly happy with it. He hasn't commented yet so either he's busy or he isn't either

I was going to try something with raster underlays for the gpsapp route screen, and worked out a way to color-reduce a geotiff using the USGS colormap standard to something which would display what I considered "interesting" information and punt the rest, and then actually thought to crop a 128x32 section and noticed it just wasn't large enough until I went to 4x zoom out.

Maybe I should play with trying to figure out saved tuner settings some more.

Top
#139990 - 13/02/2003 08:19 Re: Hijack v314: open("/dev/empeg_state",O_RDONLY) [Re: Daria]
jaharkes
enthusiast

Registered: 20/08/2002
Posts: 340
Loc: Pittsburgh, PA
Yeah, I've been kind of busy this week, so I haven't had a chance to look at the patch. btw. Why is is useful to see realtime NMEA strings? If it is to check whether the gps -> empeg connection is working, perhaps having something simple like a virtual flashing led that toggles whenever we've received serial input, and possibly flashes with a brighter color when we've actually been able to interpret this input. That would be more generic as it is applicable to the non-NMEA protocols as well.
_________________________
40GB - serial #40104051 gpsapp

Top
Page 3 of 4 < 1 2 3 4 >