The alphabetical sorting of playlist menus has been debated to death (thread, thread) but no resolution seems to be forthcoming. So...

The attached menusort executable can turn the sorting on/off. Here are semi-detailed instructions on how to use it:

- save the attachment as menusort somewhere on your computer
- install the developer player software (1.03 and 1.02 should work)
- connect via a serial cable to the empeg, e.g. with Hyperterminal (115200 bps / 8 data / no parity / 1 stop / no flow control)
- press q then Enter to get to a bash prompt
- type rw to enable read-write mode
- type rz to start the Zmodem file receive program
- use "Send File" from Hyperterminal to send menusort to the empeg
- type chmod a+x menusort to make menusort executable
- run ./menusort off to turn sorting off, or ./menusort on to turn it back on, or just ./menusort to find out what the current state is
- type ro to switch the disk back to read-only mode
- type exit

I've tested this on a mk2 with the 1.03 release. I'll be interested to hear whether it works on a mk1.

Enjoy.

Borislav

Hey, how did you pull this off!? By running the player under debugger to identify call to sort routine? Something simpler? Amazing!

Cheers!

Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green

Amazing!

I second that emotion; I've been hoping for something like this since, well, since they made it sort alphabetically, really... :)

Can't wait to try it on both my players when I get to a machine with the proper cabling available.

-----
Daniel M. Zimmerman, Caltech Computer Science
Mk.2 #060000058, 36GB
Mk.1 #00101, 10GB

Amazing. I am speechless. I have no idea how you pulled it off. Care to enlighten us?

___________
Tony Fabris

The attached menusort executable can turn the sorting on/off.

Thanks Borislav! I've been among the *many* waiting for this.

So far, I've managed to move menusort to the player, but something is keeping me from running it. Anyone out here who can help?

I think that I've managed to put the file onto the player and succesfully changed its attributes such that it now sits there (developer image 1.03) as an executable (if I guess the purpose of the chmod command correctely). This is what's on the player now:

empeg:/empeg/bin# ls -l
total 1106
-rwxr-xr-x 1 0 0 117 Jun 23 15:38 g
-rwx--x--x 1 0 0 4125 Jul 2 08:09 menusort
-rwxr-xr-x 1 0 0 1120144 Jun 23 15:38 player

But 'menusort' won't run. Everytime I type 'menusort' or './menusort', bash responds with 'Is a directory'. Like this:
empeg:/empeg/bin# ./menusort
bash: ./menusort: Is a directory

What am I doing wrong?

Henno
mk2 6 nr 6

-rwx--x--x 1 0 0 4125 Jul 2 08:09 menusort

This doesn't look right - menusort should be 4104 bytes long, not 4125. Maybe it got corrupted somewhere on the way to the empeg? The bash error message still doesn't make sense, but I'd try correcting this first.

Borislav

Hey, how did you pull this off!? By running the player under debugger to identify call to sort routine? Something simpler? Amazing!

Hehe.

I'm afraid it wasn't anything as heroic as stepping through the player one instruction at a time or reading and understanding the entire disassembled code.

Empeg publishes a partially linked player binary on their website (due to the licensing requirements of the GNU C library). I was quite surprised to find that they hadn't stripped their own symbols from that binary, so it contains many function names from the empeg source code. (I just hope I don't regret mentioning this here.) Looking through them, there were several functions with names like _introsort_loop__H3ZP8MenuItem and sort_heap__H1ZP8MenuItem (the cryptic suffixes are due to the C++ compiler "feature").

Rather than trying to read the code and figure out which of these functions calls which and when, I decided to try and get a stack trace at the point when they are called, that would immediately tell me which is the top-level sort function. I wrote a little wrapper around the strcasecmp library function that the player uses to compare the strings. Trying to put a breakpoint on that and get a backtrace with gdb got me nowhere (gdb has issues with threaded executables, and the ptrace system call that lets me attach to a process later on was also not working). So I printed the stack contents in the wrapper function and walked up the call chain manually.

A few levels up from my wrapper was a function called Sort__4Menui. I hadn't noticed it before since I searched for "sort", lowercase "s" - duh. I looked at the disassembly of that function and the first thing it does is something like "if (whatever) return;". It doesn't get any simpler than that - I just had to change the conditional branch to unconditional and the function will never do anything. At this point I took out my ARM book ("ARM system-on-chip architecture" by Steve Furber - highly recommended) and figured out the hex codes I needed to change (it was only one byte change). I tried the resulting binary and sure enough I got unsorted menus!

It was getting late that night so I left it at that. Next morning I woke up all worried. OK, I get unsorted menus, but are they actually in playlist order, or in some other order (e.g. FID order, upload order, random)? I did some tests with emplode, sorting my playlists in various ways and they all seemed to come out OK. Phew. Then I just had to write a small utility that can tweak that one byte back and forth, post on the BBS and wait for the applause.

Now let's see what other intersting symbol names they have in there...

Borislav

Very cool hack indeed. Now I've got to get gdb to understand breakpoints...

Frank van Gestel

menusort should be 4104 bytes long, not 4125

I've just saved '32844-menusort' again, and it is *again* 4125 bytes long. The funny thing is that when I click on the attachment to your original post, my Netscape attempts to display the contents. When I use the 'Save link as' option, it saves it as 32844-menusort.html (!) with the 4125 length.

Anything wrong with my browser settings?

Henno
mk2 6 nr 6

try clearing your cache before using "save as". Or try pressing shift while left-clicking the link

Frank van Gestel

try clearing your cache before using "save as". Or try pressing shift while left-clicking the link

Doesn't make any difference. It's still 4125 bytes long (both cases). Note that when pressing shift while left-clicking the link, it offers to save the link as text, or HTML. No other options. Is this normal?

--- 15 minutes later;
Made another attempt using Exploder, which downloaded 4104 bytes. Will try with the Exploder file, but am still puzzled why Netscape wouldnt download it correctly. Any ideas anyone?

--- another 15 minutes later:
The 4104 file works fine and the playlists are exactly in the order used in emplode!. Quickly tried the direct searches and everything seems to work fine. Can't see any difference (yet). Great hack Borislav! Thanks!



Henno
mk2 6 nr 6

Edited by Henno on 02/07/01 06:26 PM.

HTTP/1.1 200 OK

Date: Mon, 02 Jul 2001 17:09:46 GMT

Server: Apache/1.3.14 (Unix) PHP/4.0.4pl1 mod_ssl/2.7.1 OpenSSL/0.9.5a

Last-Modified: Sun, 01 Jul 2001 09:08:15 GMT

Etag: "185fa-1008-3b3ee87f"

Accept-Ranges: Bytes

Content-Length: 4104

Content-Type: text/plain

Age: 0

Connection: close

Via: HTTP/1.1 cam (Traffic-Server/3.0.3FCS [uScMsSfWpSeN:t cCMi p sS])

Use a different browser.


Roger - not necessarily speaking for empeg

I suspect a linefeed problem, when looking at the file it contains 21 linefeeds, and that is how
much it grows. If you're downloading on Windows it mistakenly thinks it's text and converts any
linefeed characters embedded in the file to Windows style (CRLF)...

I'm attaching a zipped up version of the file, maybe windows will recognize that and do the
right thing...

/Michael

it mistakenly thinks.

No "mistakenly" about it -- the webserver said that it was text. See my earlier posting.



Roger - not necessarily speaking for empeg

Yes, I see that now... Baaad Apache!

But, when in doubt, blame Microsoft - you'll be right most of the time

/Michael

Am attaching a zipped up version of the file

Yep! Also 4104 bytes. No problem.
Ams still puzzled why Netscape would interpret the linefeeds as data . . .

Henno
mk2 6 nr 6

when in doubt, blame Microsoft

Are you saying that MS *should* have dowloaded 4125 bytes, but did it right because it misinterprets the content type ? ? ?

Henno
mk2 6 nr 6

Then I just had to write a small utility that can tweak that one byte back and forth, post on the BBS and wait for the applause.



(Closest I could come to applause in the BBS markup language.)


One question: The byte-tweaker... Does it just pick a specific byte offset in the file, or does it do a "search" for the bytes around it, or both?

I'd hate to think someone running it against a 1.02 player could crash their player software.

___________
Tony Fabris

Am still puzzled why Netscape would interpret the linefeeds as data . . .

This is a standard problem with downloading files that aren't in the server's "MIME types" list.

For a while, Empeg's own support site didn't have the ".upgrade" file in its MIME types, so anyone downloading an upgrade file with Netscape got a corrupted file.

You never know when it's going to happen, because any server could have its MIME types screwed up.

My solution? I've quit downloading files with web browsers altogether. I use GetRight exclusively for all my downloads. It never has this problem.

___________
Tony Fabris

One question: The byte-tweaker... Does it just pick a specific byte offset in the file, or does it do a "search" for the bytes around it, or both?

It's reasonably paranoid - it searches for 64 bytes around the one it wants to tweak. It only does it if it finds exactly one instance of those bytes. If it does break your player you can always tweak the byte back to fix it. It should be quite safe.

Borislav

Content-Type: text/plain

Argh. OK, that makes sense. The fact that netscape tries to display the file should have made me suspicious...

Thanks,
Borislav

In reply to:

---

post on the BBS and wait for the applause.

---

That will have to wait until that splitting headache I got from reading your post. I have no idea what you said.



No seriously cool stuff. Hugo is likely to skin you alive though.

Cheers,
Hans


Mk2 - Blue & Red - 080000431

I was about to write something similar.
I use FlashGet though, abit different, but similar.

Check out http://www.amazesoft.com/

TommyE

> > when in doubt, blame Microsoft
> Are you saying that MS *should* have dowloaded 4125 bytes, but did it right because it misinterprets the content type ? ? ?

No, MS should have downloaded 4125 bytes, but did it wrong because it misinterprets the content type...

The webserver is telling it that it's a plain text file. When downloading a text file, a browser should adapt the line endings in the file to the local custom. UNIX uses single LF characters (0x0A), DOS uses CRLF pairs (0x0D0A), so Netscape correctly adds a CR to any single LF it finds, which is why the file is bigger, and also why it doesn't work anymore...

The problem here is that the webserver is not configured correctly. It should be reporting a binary content type such as application/x-octetstream. It's the webserver's resposibility to determine the type of a file, not the web browser's...

That headache of mine is not getting better

Hans


Mk2 - Blue & Red - 080000431

I didn't know about partially linked player object module, but still amazing hack! Congratulations again!

Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green

That's why I almost always zip whatever is in danger of being downloaded through a browser...

Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green

Just wanted to say Thank You. Simply great. Quick and easy :))

Taym
______________________________
EMPEG MK II BLUE 12GB 090000923

I was under the impression that the Empeg now displayed all playlists in alphabetical order? I am sure mine is,.. maybe i don't pay enough attention.???

do i misunderstand what this hack accomplishes?

This hack enables the playlists to be in 'position' order instead of alphabetical order. Great hack, I love it!

-Chuck