#250983 - 04/03/2005 16:21
Re: set_empeg_max_fid (version 5 binary)
[Re: mlord]
|
carpal tunnel
Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
|
Quote: Mmm.. I wonder what might happen if we also patched the 0000 0010 (0x1000) value to a larger number, and adjusted max_fid to compensate.. Peter?
Crikey. OK. What you'd have to do is observe that (0x00001000, 0x00007000) is the ninth and last in an array of (offset,size) pairs. The first four pairs correspond to bookmarks 0-3. "Bookmark Zero" is the saved playlist, and bookmarks 1-3 are the user-visible bookmarks.
As shipped, the four bookmarks are 512 sectors long each (256K bytes). If you were being devious, you could sacrifice one or two bookmarks to the greater good, and increase the size of Bookmark Zero. So the table starts like this: (0x00000000, 0x00000200) (0x00000200, 0x00000200) (0x00000400, 0x00000200) (0x00000600, 0x00000200) and if you changed it to be, say (0x00000000, 0x000003C0) (0x000003C0, 0x000003C0) (0x00000780, 0x00000040) (0x000007C0, 0x00000040) then both the saved playlist and Bookmark 1 would have much more space, but Bookmarks 2 and 3 could be used only for shortish running orders. Blah blah no guarantee that doesn't shag it royally etc. but it should work.
If you were being proper devious, and you had lots of room (say 0xBC42 sectors, like Paul), you could remap some at the end of the paritition, on the basis no-one has more than say A000 fids: (0x00000000, 0x00000400) (0x00000400, 0x00000400) (0x0000B000, 0x00000400) (0x0000B400, 0x00000400) ... (0x00001000, 0x0000A000) (not AC42)
You shouldn't fiddle with or move the small, 16-sector allocations in the middle of the list: (0x00000800, 0x00000010) and its friends.
Peter
|
Top
|
|
|
|
#250984 - 04/03/2005 19:08
Re: set_empeg_max_fid (version 5 binary)
[Re: peter]
|
carpal tunnel
Registered: 19/01/2002
Posts: 3584
Loc: Columbus, OH
|
<coy>Ooh I love it when you get proper devious</coy>
_________________________
~ John
|
Top
|
|
|
|
#250985 - 04/03/2005 20:29
Re: set_empeg_max_fid (version 5 binary)
[Re: peter]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Mmm.. great(!) info, Peter!
Now, as I seem to recall.. the current running order has a fixed 512-byte overhead, plus something like 12-bytes per FID, so the default of 256KB can handle up to 21802 FIDs, I suppose.
I think the simplest thing to do, for players with lots of "slack" on /dev/hda3, would be to have set_empeg_max_fid move the running order to the end of the partition, sized to match the new max_fid value. The space vacated at the beginning of the partition could then be redistributed among the bookmarks.
Nice, simple, safe, and probably a Good Thing(tm) to have it do.
Right?
EDIT: or maybe just swallow the bookmarks into an expanded running order (up to new max_fid), and relocate the affected bookmarks to the end of the partition.. mm.. I might like this option even more.. mmm..
Edited by mlord (04/03/2005 20:38)
|
Top
|
|
|
|
#250986 - 04/03/2005 20:46
Re: set_empeg_max_fid (version 5 binary)
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Mmm... yes.. I like Peter's second option.. cannibalize the 3rd & 4th bookmarks to expand the first two, and then reallocate the 3rd/4th from the slack space at the end of the partition.
-ml
|
Top
|
|
|
|
#250987 - 04/03/2005 21:15
Re: set_empeg_max_fid (version 5 binary)
[Re: mlord]
|
carpal tunnel
Registered: 05/01/2001
Posts: 4903
Loc: Detroit, MI USA
|
If this works (and I'm sure it will) it will be SO appreciated! This has been the number one nusance with my player for a long time. It's just a great way to rediscover music on your player.
_________________________
Brad B.
|
Top
|
|
|
|
#250988 - 05/03/2005 02:25
Re: set_empeg_max_fid (version 5 binary)
[Re: peter]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Quote: You shouldn't fiddle with or move the small, 16-sector allocations in the middle of the list:
(0x00000800, 0x00000010) and its friends.
What about the gap between 0x0820 and 0x1000?
That's a nice 0x7e0 sectors worth of space.. is it really available? I'd like to put bookmark #4 there.
Cheers
Edited by mlord (05/03/2005 03:06)
|
Top
|
|
|
|
#250989 - 05/03/2005 03:13
Re: set_empeg_max_fid (version 5 binary)
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Quote: >You shouldn't fiddle with or move the small,
>16-sector allocations in the middle of the list:
>(0x00000800, 0x00000010) and its friends.
What about the gap between 0x0820 and 0x1000?
That's a nice 0x7e0 sectors worth of space.. is it really available?
I'd like to put bookmarks 3 and 4 there.
Doing so, the offsets table would then look like this:
before:
00112668: 00000000 00000200 00000200 00000200
00112678: 00000400 00000200 00000600 00000200
00112688: 00000800 00000010 00000810 00000010
00112698: 00001000 00007000 00000000 00000000
after:
00112668: 00000000 00000400 00000400 00000400
00112678: 00000820 000003f0 00000c10 000003f0
00112688: 00000800 00000010 00000810 00000010
00112698: 00001000 00007000 00000000 00000000
EDIT: Oh, wait.. v3alpha8 appears to have a different layout.. but everything from 0x840 to 0x1000 still appears vacant.
I now have an unreleased v7 of the utility now that fiddles the bookmarks to larger sizes using this space.
???
Edited by mlord (05/03/2005 03:43)
|
Top
|
|
|
|
#250990 - 05/03/2005 18:42
Re: set_empeg_max_fid (version 5 binary)
[Re: mlord]
|
carpal tunnel
Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
|
Quote: What about the gap between 0x0820 and 0x1000?
It's currently unused, but just in case we need some more (this isn't very likely), try just using 0x880...0x1000.
Peter
|
Top
|
|
|
|
#250991 - 05/03/2005 18:48
Re: set_empeg_max_fid (version 5 binary)
[Re: peter]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Quote:
Quote: What about the gap between 0x0820 and 0x1000?
It's currently unused, but just in case we need some more (this isn't very likely), try just using 0x880...0x1000.
Peter
Ha! That's what I already chose, and for exactly that reason.
Okay v7 now does all of this nicely. I'll release it sometime this week.
Cheers!
|
Top
|
|
|
|
#250992 - 05/03/2005 22:18
set_empeg_max_fid (version 7 source)
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Here is version 7 of set_empeg_max_fid.c
This one does the same max_fid fixes as prior versions, but now also expands the stored running order and bookmarks sizes to handle larger numbers of fids.
Run this on *any* player version to gain support for:
-- running orders (Eg. down-down-down shuffles) of up to 43648 fids, which should now survive reboots with this fix.
-- larger bookmark capacities (a bookmark is merely a saved running order): 43648 fids for bookmark #1, and 40917 fids for bookmarks #2 and #3.
Those features will work regardless of disk size.
In addtion, v7 will automatically reconfigure any slack space at the end of the dynamic data partition on the player (/dev/hda3) for use with fids > 0x6fff, according to available space. The larger the drive, the larger the (free!) gain one typically sees from this.
Cheers
Attachments
250633-set_empeg_max_fid.c (367 downloads)
|
Top
|
|
|
|
#250993 - 05/03/2005 22:20
Re: set_empeg_max_fid (version 7 source)
[Re: mlord]
|
carpal tunnel
Registered: 05/01/2001
Posts: 4903
Loc: Detroit, MI USA
|
Thank you, thank you, thank you! You rock Mark. It's like Christmas here! I'll test it once there is a version ready for the empeg.
_________________________
Brad B.
|
Top
|
|
|
|
#250994 - 05/03/2005 22:20
Re: set_empeg_max_fid (version 7 binary)
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Here is the empeg (executable) binary for set_empeg_max_fid.v7 (attached).
Sample output from one of my players running v2.01:
# /set_empeg_max_fid.v7
set_empeg_max_fid.v7: version 7 by Mark Lord (March 2005)
/dev/hda3: 33264 sectors
New max_fid value will be 29168 (000071f0)
before:
00112888: 00000000 00000200 00000200 00000200
00112898: 00000400 00000200 00000600 00000200
001128a8: 00000800 00000010 00000810 00000010
001128b8: 00001000 00007000 00000000 00000000
after:
00112888: 00000000 00000400 00000400 00000400
00112898: 00000880 000003c0 00000c40 000003c0
001128a8: 00000800 00000010 00000810 00000010
001128b8: 00001000 000071f0 00000000 00000000
Cheers
Attachments
250635-set_empeg_max_fid.v7 (565 downloads)
|
Top
|
|
|
|
#250995 - 05/03/2005 22:30
Re: set_empeg_max_fid (version 7 binary)
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
And here is similar sample output from a v3a8 player. Note the extra line of output in both the before and after portions:
# /set_empeg_max_fid.v7 set_empeg_max_fid.v7: version 7 by Mark Lord (March 2005) /dev/hda3: 33264 sectors New max_fid value will be 29168 (000071f0) before: 0017a950: 00000000 00000200 00000200 00000200 0017a960: 00000400 00000200 00000600 00000200 0017a970: 00000800 00000010 00000810 00000010 0017a980: 00000820 00000010 00000830 00000010 0017a990: 00001000 00007000 00000000 00000000 after: 0017a950: 00000000 00000400 00000400 00000400 0017a960: 00000880 000003c0 00000c40 000003c0 0017a970: 00000800 00000010 00000810 00000010 0017a980: 00000820 00000010 00000830 00000010 0017a990: 00001000 000071f0 00000000 00000000
Cheers
|
Top
|
|
|
|
#250996 - 05/03/2005 22:32
Re: set_empeg_max_fid (version 7 binary)
[Re: mlord]
|
carpal tunnel
Registered: 05/01/2001
Posts: 4903
Loc: Detroit, MI USA
|
Worked perfectly! It's been SOO long since I've been able to save my root playlist! Thank you!
Now I just need the balls to run Alpha8 on this thing so I can crossfade.. hehe.
Edited by SE_Sport_Driver (05/03/2005 22:34)
_________________________
Brad B.
|
Top
|
|
|
|
#250997 - 06/03/2005 09:21
Re: set_empeg_max_fid (version 7 source)
[Re: mlord]
|
pooh-bah
Registered: 13/09/1999
Posts: 2401
Loc: Croatia
|
Sigh, the last excuse for not upgrading disks and memory gone....
_________________________
Dragi "Bonzi" Raos
Q#5196
MkII #080000376, 18GB green
MkIIa #040103247, 60GB blue
|
Top
|
|
|
|
#250998 - 06/03/2005 10:27
Re: set_empeg_max_fid (version 7 source)
[Re: mlord]
|
carpal tunnel
Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
|
Quote: -- running orders (Eg. down-down-down shuffles) of up to 43648 fids, which should now survive reboots with this fix.
It's actually not quite as simple a calculation as that. Each bookmark, including the saved running order, saves both the shuffled and unshuffled order. So the space taken up is 512 bytes, plus 8 bytes per distinct fid (i.e. 8 times the length of the shuffled running order), plus 4 bytes per appearance of each fid (i.e. 4 times the length of the unshuffled running order). Calculations based on "12 bytes per fid" are only accurate if each fid appears in only one playlist. If each fid appears in an average of two playlists, it's 16 bytes per fid -- three playlists, 20 bytes per fid, and so on.
Peter
|
Top
|
|
|
|
#250999 - 06/03/2005 11:53
Re: set_empeg_max_fid (version 7 source)
[Re: peter]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Right. I figured something like that, thus the up to wording.
In practice, on one of my own players with around 7000 tracks, this can now make a difference on down-down-down shuffles. So one doesn't even need to be in Paul's league to benefit.
Cheers
|
Top
|
|
|
|
#251000 - 06/03/2005 13:16
Re: set_empeg_max_fid (version 7 source)
[Re: mlord]
|
carpal tunnel
Registered: 15/08/2000
Posts: 4859
Loc: New Jersey, USA
|
Although, it certainly helps. Thanks again!!!
_________________________
Paul Grzelak 200GB with 48MB RAM, Illuminated Buttons and Digital Outputs
|
Top
|
|
|
|
#251001 - 06/03/2005 16:57
Re: set_empeg_max_fid (version 7 source)
[Re: pgrzelak]
|
carpal tunnel
Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
|
Quote: Although, it certainly helps. Thanks again!!!
You know, even though many of the usual suspects seem to be reading this thread already, it's probably worth a new thread somewhere titled as a cure for forgotten down-down-down running-orders -- it seems a shame to have such useful hackery hidden in a thread apparently about memory boards.
Peter
|
Top
|
|
|
|
#251002 - 06/03/2005 18:14
Re: set_empeg_max_fid (version 7 source)
[Re: peter]
|
carpal tunnel
Registered: 08/06/1999
Posts: 7868
|
Quote: it's probably worth a new thread
Done. tearing this subthread out where I did seemed to be the cleanest way to do it without duplicating posts. Forgot the new board lets me do that easially.
|
Top
|
|
|
|
#251003 - 06/03/2005 18:17
Re: Patching the Player for more dynamic FIDs
[Re: mlord]
|
carpal tunnel
Registered: 05/01/2001
Posts: 4903
Loc: Detroit, MI USA
|
Forgive my "gushing", but I am just LOVING the fact that I can start shuffleing the root playlist again!
_________________________
Brad B.
|
Top
|
|
|
|
#251004 - 06/03/2005 23:18
Re: set_empeg_max_fid (version 7 source)
[Re: drakino]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
|
Top
|
|
|
|
#251005 - 15/03/2005 17:46
Re: set_empeg_max_fid (version 7 binary)
[Re: mlord]
|
pooh-bah
Registered: 09/08/2000
Posts: 2091
Loc: Edinburgh, Scotland
|
Not getting this to work at all. When I run it I get:
empeg:/# ./max_fid.v7 max_fid.v7: version 7 by Mark Lord (March 2005) /empeg/bin/player: Text file busy empeg:/#
What would this mean?
_________________________
Rory MkIIa, blue lit buttons, memory upgrade, 1Tb in Subaru Forester STi MkII, 240Gb in Mark Lord dock MkII, 80Gb SSD in dock
|
Top
|
|
|
|
#251006 - 15/03/2005 18:44
Re: set_empeg_max_fid (version 7 binary)
[Re: frog51]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
That would mean you should first kill off the player app (serial port: control^C) before trying to modify it.
|
Top
|
|
|
|
#251007 - 15/03/2005 18:58
Re: set_empeg_max_fid (version 7 binary)
[Re: mlord]
|
pooh-bah
Registered: 09/08/2000
Posts: 2091
Loc: Edinburgh, Scotland
|
Darn - I was afraid of that. Now I need to go and find that serial cable Cheers Mark
_________________________
Rory MkIIa, blue lit buttons, memory upgrade, 1Tb in Subaru Forester STi MkII, 240Gb in Mark Lord dock MkII, 80Gb SSD in dock
|
Top
|
|
|
|
#251008 - 15/03/2005 19:04
Re: set_empeg_max_fid (version 7 binary)
[Re: frog51]
|
carpal tunnel
Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
|
Just kill -2 <pid>
_________________________
Bitt Faulk
|
Top
|
|
|
|
#251009 - 15/03/2005 19:07
Re: set_empeg_max_fid (version 7 binary)
[Re: frog51]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
It can be done entirely over FTP if really necessary, just requires a few more hoops to jump through:
-- remount rw: site rw -- rename the existing /empeg/bin/player to something else -- make a new copy of it under the original name -- chmod 755 on the new copy (original name) -- delete the original (now renamed) file (yes, you can do that even while it is still running) -- patch the new one (original name) -- remount ro: site ro -- reboot: site reboot
Cheers
|
Top
|
|
|
|
#251010 - 15/03/2005 21:31
Re: set_empeg_max_fid (version 7 binary)
[Re: mlord]
|
pooh-bah
Registered: 09/08/2000
Posts: 2091
Loc: Edinburgh, Scotland
|
Sounds reasonable, but I bet I could have messed up something trying those steps (can you tell I used to be a programmer, so instead I spent 15 minutes looking for the cable and now all is well.
I only have 14000 tracks so hadn't had a fail on down, down, down - but it seems to cope with it faster now. There used to be a significant pause before.
So, many thanks!
_________________________
Rory MkIIa, blue lit buttons, memory upgrade, 1Tb in Subaru Forester STi MkII, 240Gb in Mark Lord dock MkII, 80Gb SSD in dock
|
Top
|
|
|
|
#251011 - 15/03/2005 21:32
Re: set_empeg_max_fid (version 7 binary)
[Re: wfaulk]
|
pooh-bah
Registered: 09/08/2000
Posts: 2091
Loc: Edinburgh, Scotland
|
ahhh - never thought of trying -2, and obviously -9 just kept respawning
_________________________
Rory MkIIa, blue lit buttons, memory upgrade, 1Tb in Subaru Forester STi MkII, 240Gb in Mark Lord dock MkII, 80Gb SSD in dock
|
Top
|
|
|
|
#251012 - 15/03/2005 22:54
Re: set_empeg_max_fid (version 7 binary)
[Re: frog51]
|
carpal tunnel
Registered: 24/12/2001
Posts: 5528
|
Faster? There shouldn't be any speed difference.
|
Top
|
|
|
|
|
|