#139934 - 05/02/2003 23:03
Re: Where is the number of plays stored?
[Re: Daria]
|
Carpal Tunnel
Registered: 08/02/2002
Posts: 3411
|
Derrick, remember that the eq is selectable between 2x10 or 4x5 channels.
_________________________
Mk2a 60GB Blue. Serial 030102962
sig.mp3: File Format not Valid.
|
Top
|
|
|
|
#139936 - 05/02/2003 23:19
Re: Where is the number of plays stored?
[Re: Daria]
|
Carpal Tunnel
Registered: 08/02/2002
Posts: 3411
|
I don't know whether that'd match with anything in kernel land, and whether taking a look at arch/arm/special/empeg_mixer.c (and friends) would help. If the player is storing the raw values as written to the kernel's IOCTLs then they may match up. If the player is storing 'user-friendly' values and converting on the fly, then probably not.
_________________________
Mk2a 60GB Blue. Serial 030102962
sig.mp3: File Format not Valid.
|
Top
|
|
|
|
#139950 - 06/02/2003 20:47
Re: Where is the number of plays stored?
[Re: Daria]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
Hey Derrick (or Peter if you're still tuned into this thread.)
Where's the current running order (not playlist) stored? If I could programmatically get the FID of the next and previous songs, it'd help me a lot so I can cache the lyrics. Otherwise, it can take a good 3-5 seconds while the player and the lyrics scroller are both trying to read the MP3 fid at the same time. I'd love to be able to cache a few songs in advance.
|
Top
|
|
|
|
#139955 - 07/02/2003 18:51
Re: Where is the number of plays stored?
[Re: tonyc]
|
enthusiast
Registered: 14/05/2001
Posts: 279
|
Wow, I'd be interested in the current running order also. If Mark was nice enough to make this available in XML like the playlists, I could include the current running order in the web interface (default page, below the now playing).
Tom
|
Top
|
|
|
|
#139956 - 07/02/2003 19:15
Re: Where is the number of plays stored?
[Re: charcoalgray99]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14484
Loc: Canada
|
I am not sure that the current running order is actually stored ANYWHERE.
If it's a premade playlist that's running, well.. the FID for the playlist is stored in the flash savearea, along with the FID of the currently playing track.
If it's a randomly convoluted playlist, then they probably just do the randomization on the fly, with known randomizer seed (maybe also stored in the flash savearea?). They could step forward/back through the "playlist" by just (re)generating the pseudorandom sequence on the fly.
???
|
Top
|
|
|
|
#139957 - 07/02/2003 19:22
Re: Where is the number of plays stored?
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14484
Loc: Canada
|
Actually, I partially take that back.. the current playlist FID is NOT stored in the flash savearea.. and I don't see any "randomizer" or "playlist position" fields in the savearea, either.
So the playlist FID must be on disk (dynamic data partition) somewhere, but there's still no need to store the entire playlist there, as playlists are already in the database. For a random shuffle, they just need to keep track of the random seed, so it could be regenerated on the fly. I don't know if "order tweaks" survive power loss -- anybody?
??
|
Top
|
|
|
|
#139958 - 07/02/2003 20:01
Current playlist and order
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14484
Loc: Canada
|
Okay, nevermind, the current play order IS on the dynamic partition -- Peter even said so, I just missed it earlier.
The first 512 sectors (each sector is 512 bytes long) of /dev/hda3 is used for the current play order. Here's what I know thus far, using a short playlist:
There is something resembling the playlist, but incomplete, in the first sector. In particular, the early entries in this playlist appear to have been zeroed out, but otherwise it is in the same format as what I report below:
In the second sector, is the playlist, stored 8-bytes per entry. Within each entry, the first 4-bytes are the FID (little endian byte order), and the second 4-bytes appear to be the same for all FIDS, at least that's the way it looks for my simple 3-album playlist test case. Let's call this the "FID table".
I do not know what determines the size of the playlist, but immediately following it on disk is the play sequence, with 4-bytes per entry. Each entry consists of a 4-byte (liitte endian byte order) position index for the "FID table". When the playlist is not being shuffled, these are simply the values 0, 1,2,3,4,5,.. in sequence. But press "Shuffle" on the remote, and then look at it again (after the disk activity indicator goes on and then off again..), and you'll see the same position indexes, but now in a randomized order, such as: 1a,c,14,16,7,0,9,f,..
The same wierd position indexes can be seen in the first sector as well.. shuffled there as well.
One could presume that for a longer playlist, these two copies of the running order will each span multiple sectors, instead of being contained within the first and second sectors.
The way I'm poking at this is easy: I just pop up the Hijack "Vital Signs" screen, and watch the FID change as I use the FRONT PANEL BUTTONS to change tracks. This gives me the running order, and allows me to move forward/back at will, and see the effects of shuffling. Then I also do a hexdump of the first 512*512 bytes of hda3 (fetch it from the player using httpd, and then dump it in hex using tools on my Linux box).
Okay, somebody else take over now.
Cheers
|
Top
|
|
|
|
#139959 - 07/02/2003 20:11
Re: Where is the number of plays stored?
[Re: mlord]
|
Carpal Tunnel
Registered: 08/02/2002
Posts: 3411
|
Yep, tweaks are retained over a power cycle according to my quick test - Whole player shuffled, 'Hate Artist' on first 4 artists, 'Like Artist' * 3 to get first 4 tracks by the same artist. Track count and shuffle order both restored as expected.
I wonder whether this is the reason that selecting a new playlist sometimes takes a while - a small playlist seems to load immediately, whereas a long playlist 'hourglasses' (Disks already spun up in both cases, shuffle off). Since the whole database is already in RAM, and we only need to know what the first 4 tracks are for display purposes, database access doesn't explain it. In both cases we only need to start caching the first track before starting, so that doesn't explain it either. But if we needed to write the running order to the dynamic data partition then that would be dependant on playlist size.
_________________________
Mk2a 60GB Blue. Serial 030102962
sig.mp3: File Format not Valid.
|
Top
|
|
|
|
#139960 - 08/02/2003 10:05
Re: Current playlist and order
[Re: mlord]
|
carpal tunnel
Registered: 13/07/2000
Posts: 4174
Loc: Cambridge, England
|
One could presume that for a longer playlist, these two copies of the running order will each span multiple sectors, instead of being contained within the first and second sectors. Yes. One could also notice that this area isn't really big enough at 512 sectors or 256K. If, in your playlists, you've got four references to each FID (say, once in an Artists playlist tree, once in Decades/Years, once in Genre, and an average of once more in ad-hoc playlists) then playing the whole player with down-down-down uses 24 bytes in this area for each track (8 for the "FID table", known as the "programme" in the player code, and four lots of 4 for the "play sequence", known to us as the "running order"). 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), and play all of them, then it won't be able to remember your playlist over a power-down. This is a genuine reported problem, and a much bigger spur to completely reorganising the dynamic partition than the 28,000-or-so limit on the per-FID dynamic area. But, as I said, we won't get round to this for 2.0final. Incidentally, there are three more 512-sector-long playlist dump areas at offsets 512, 1024 and 1536: the three bookmarks. Peter
|
Top
|
|
|
|
|
|