So, I believe Mark Lord is due back today or therebouts...when do you guys think it would be reasonable to expect the next HiJack release? Hours? Days? Any bets?

I thought he was gone for the whole month.

Dang, did I miss read it? Did it say for "the" month instead of for "a" month... rats. Now I gotta go check it...

I think that if he had taken a computer with him, he'd be working on a new version during the flight. If he hasn't already cranked out a couple of versions while on the cliffs.

I'm just waiting to see how much has changed while I'm away for a while in January. Well, if I don't check in from the US (I probably will seeing as I'll be surrounded by computers all day :)

Bruno

Guys... If I may be so bold...

The title of this thread is Hijack v74. That means that there are many people eagerly anticipating the seventy-fourth release of the Hijack mods. Wow! Mark Lord devoting some of his programming muscle to the Empeg has been quite a nice turn of events, and we all have some really nice functionality with the robust IR translation, screen blanker, etc. And, of course, the breakout game...

But the real power of what's *already available* in the kernel mods (and has been there since v30 or thereabouts) has not even been explored, and that's the ability to run user applications, bind to the menu, and control the display and receive input. Now all of the wonderful ideas that people have batted around in the forums can finally become a reality, and they can fit in beautifully with the Empeg's interface. Huzzah!

But wait.. where are the goods? Where have all the programmers disappeared to? I thought after this "holy grail" showed up, hackers would be tripping over each other to release new fun extensions to the Empeg... Be it silly games, maybe porting Emptris to the new hijack interface, a lyrics scroller, various information scrollers in overlay mode.. Whatever. There were dozens of ideas thrown around in the programming forum before the hijack mods were around.

I know not everyone (and not even a majority of the people here) are experienced enough to be able to write user applications/games/etc for the Empeg, and that's fine. I also know many of those who do have the programming talent are busy with their real jobs, their real lives, etc... Especially during the holidays. But the thing is, Mark has done a lot of work to build a bridge between user applications and the Empeg interface, and now we need to start backing that effort up with some development on the user side. Mark has made it clear a few times on these forums that he is hoping to see some real effort from the many talented folks we have scattered around the world, and I guess I'm just not seeing it. Even before the holidays I wasn't seeing it. Maybe there are twenty people working on top secret efforts that they're just not ready to share yet, but I haven't heard about anything yet.

I know that Rome wasn't built in a day. Heck, it took me several weeks to get even an alpha version of my trivia game out, and it's still far from perfect (though quite usable.) It's slow and it's raw, but it works.. I was hoping to see at least hints that other people were planning on doing stuff which integrates with the hijack kernel, and I'm a little disappointed that we're sitting around here waiting for new releases of the kernel when the real magic of the kernel is already in there... I see any changes Mark makes now as "bells and whistles" and maybe a few refinements... The real power is now in the hands of all of us Joe Linuxes around here, so let's do something with it instead of waiting for v9241 of the hijack kernel.


Disclaimer: This post is in no way directed towards those who have already spoken here, it's more of a general comment on the stagnant state of development on the Empeg lately.

I guess there just hasn't been a lot of advertisement on the subject, at least that I've seen. Until your post, I though Hijack was *only* a breakout game.

Greg

I agree, I was hoping to see displayserver working from the hijack menu along with some type of complete backup utility. If I was a programmer, I would try it myself, but im not :-( Something that would back up all mp3s, playlist structure, and eq settings would be awesome!

Sean

Sean

OK. Here's where I got it from (as posted on 11/11 and not really in reply to)

In reply to:

---

Maybe someone will cobble it together while I'm away for the next 5 weeks.

---

And by my calculations that was over last Monday or so I thought. On closer inspection the calendar that I was marking time on is one of those which puts all the partial weeks on the first row of the month and I'd thrown an extra week in there. Dang. He doesn't get back until next week....not that I'm counting .

so someone has a week to "cobble" something together :-)

You folks are just so behind the times..

v74 has been out for *hours* now, and I just popped up a v75 as well.

Nothing exciting, though, just a couple of small bug fixes:

v74: Fixed config.ini voladj settings to apply immediately on player reboots (voladj settings from config.ini were not actually taking effect unless one went into the menu and toggled the voladj setting after each reboot.. ugh).
v75: Prevent hijack from interfering with equalizer setup screens (so the knob can be used to move among equalizer settings again..)

I think I may add a program launching mechanism to config.ini next, perhaps with menu integration as an option..

But what I'd really like to work on is generic http upload/download capability from within the kernel, sort of like an extension to khttpd, but with directory listing and upload capabilities. If we can pull this one off, then the installation/backup/restore/displayserver stuff could all just sit on top of it without any further kernel mods. Dunno if I can do it, though..

So much for the debates on when you'd be back... :)

Bruno

Mark, If you actually manage to create this backup basic interface... well... you become my hero! Maybe that's not the most desider prize, but...

Jokes apart, that's just fantastic, we do NEED a backup utility. Anything that allows you to take what's on the empeg and copy it on the hdd AND VICE VERSA, that's what we really need. Please, go ahead, that's the most important of all the features of HiJack! And a big thank you, of course!

Mark, If you actually manage to create this backup basic interface... well... you become my hero!

I'm going to say this again...

Kernel support from Mark is not necessary to write a backup utility. There is enough information in the Emptool source code for someone to write a completely standalone backup utility that requires nothing but the consumer software to be installed on the player. This has already been demonstrated with a command-line utility (posted on this BBS) that can retrieve a file from the player via ethernet.

Apparently nobody noticed, but JEmplode has this functionality. You can download individual files as well as entire playlists.

-Mike

amold wrote a backup utility a while back. I used it and it worked fine.

I tried to use it but I get failure when it is checking media

the player works with emplode

You said more than once, yes, and yet nobody has come out with anything that really performs a proper backup that restores everything back in one step. So, hopefully this new feature of hijack will work as an incentive for those in here who have good coding skills to make such a backup utility!

Can you restore files back to the empeg? Does jemplode also save on hdd the database frim the emepg, so that you don't lose all the info added in the empeg day by day?

I seriously doubt if anyone is actually going to make such a backup/restore util. The reason being that even if the coding were trivial it would take a very brave developer to repeatedly test the restore code on their own empeg. The chances of not trashing data while testing such a beast are fairly small.

I guess your best hope if that one of the people with "spare" empegs laying around might take the plunge...

Now if someone took the existing code for emptool, made it work over USB on Windows and wrapped a set COM classes around it then I might volunteer to do the UI side of it in VB (I would need the USB support as I would want to test it initially on my Mk1).

Well, people do have spare Empegs, I'm one of them and would be happy to try a restore utility out... But if you think about it, if someone has the backup utility, they probably don't care about messing up the data on their Empeg. They can just re-Emplode their tunes if something goes awry... Right?

That assumes that their backup/restore util works, which is exactly what they would be testing at the time...

It assumes that the backup part of the util worked and got all the data (including all the playlists and all the tag edits that have occured since the mp3 was uploaded to the empeg initially). There is a whole bunch of stuff that could go wrong while testing such a tool that could lose you your data.

If it was as simple as just backing up the mp3 files and then using emplode to put them back then we wouldn't need to be talking about a backup util as as JEmplode would do all we needed. But a backup tool needs more than this if you have editted the tune tags on the empeg.

Anyway, as I have a spare empeg that part of it isn't such a problem for me. My problem is that I don't do C++ and so can't make use of the emptool C++ source unless someone wraps it in a nice COM interface for me to use from VB.

Ah okay I must admit that I haven't followed this thread closely and wasn't aware that you were talking about not just the MP3's but also the Empeg database, config.ini, etc. Yes, testing that restore util would be somewhat risky.

Anyway, whoever writes such a util need not have a backup Empeg, they have people like us who could test it for them... But someone who has a backup Empeg would be an ideal candidate for writing it. I'm more of a Unix C guy myself, I can program in C++ and MSVC, but usually choose not to. I would be more than happy to test such a utility for anyone who wants to write it though, as I have my original MkII sitting lonely in my closet.

To be honest I don't need a backup/restore tool anyway. What I need is something that generates an MD5 hash for every mp3 on my empeg and every mp3 on my PC and then goes through the empeg copying editted tags to the mp3s on my PC.

Alternatively I could learn to edit the tags before uploading, but that's just too easy isn't it...

Can you restore files back to the empeg? Does jemplode also save on hdd the database frim the emepg, so that you don't lose all the info added in the empeg day by day?

You can upload files back to the empeg the same way you do with emplode. You can not retrieve the DB or any of the settings stuff. I am pretty sure that the protocol from emptool does not allow you grab any of this content. Personally I never understood why anybody would want this type of backup tool. I can see wanting to get mp3s of the unit, but the rest of the stuff is easy enough to redo. If you didn't setup the tags right in the first place that is really your own fault.

-Mike

>Kernel support from Mark is not necessary to write a backup utility.

I agree, but I'm not sure that the emptool interface is complete enough to do it either.

But for that matter, I personally am not really interested in a backup/restore, since I do it the other way around. I set up my .mp3 directories on my host Linux TBird system, and then "mirror" that onto the empeg. If the empeg dies, I just re-mirror onto a new unit/drive/whatever. Any playlist changes I make are similarly done..

But I would like an easier way for me to poke about on the player, without having to do anything more complex than a kernel download. That's why I think a two-way khttpd would be nice -- otherwise I'd just install a stripped down usermode httpd instead, and be done with it!

So.. don't y'all hold yer breaths waiting for backup/restore capability from me, but if the itch gets prickly enough, I just might do something along those lines for my own benefit (and pass it on as usual). But we're talking Jan/Feb timeframe at the earliest for this.

Cheers

-ml

They can just re-Emplode their tunes if something goes awry... Right?

What about the hours some people have spent modifying their music database? It's easy to emplode a huge list of files if you have them around, but a restore of the database structure and customized fields (for playlists and tunes) is the biggest thing.

Right now I'd really like the ability to run emplode in an "offline" mode to manipulate a database on my PC. I'd also love for it to then support modifying the ID3 tags of tunes. This would allow a lot of editing and changes to be made and then a sync whenever you had the time - not necessarily then and there. I've been using MP3Tag Studio for tag corrections and it's great for directory-loads of files, but it doesn't touch the batch possiblities of emplode when sorting by tag fields.

Bruno

A mirror is exactly what I would like to do, but I have no idea how to go about it. I would like to maintain a directory structure on my pc, i could add, change, or delete files. Then next time I synced my empeg, all the changes I made would be uploaded and changes made to its database. Is this at all posible with the emptool source that we have been given?

The protocol *does* let you get the database. For starters, it reads it as soon as you connect to the remote unit so you can navigate about in it.

The database is built from all the *1 files on the drive. If there is no database, the player rebuilds it by reading all the *1 files.

Basically, if you back up the fids directory (ie, all the mp3 files, all the playlist files, all the *1 files) then you have the database & structure in there.

Hugo

The protocol *does* let you get the database,

OK, now that I think about it I guess it would have to, but how about arbitrary files? Say I want to backup my custom /sbin/init? Or somehow grab my equalizer settings (which are not available as a regular file IIRC)? These are the kind of things people seem to want when they ask for a full backup and which I assume are not possible short of dd'ing the drives.

-Mike

I have to agree there. I have close to 3000 tunes in my empeg, and perhaps 2500 of them have no id3 tags what so ever. I've spent a considerable amount of time making sure the tags and playlists are just "right." It is not a mirror, and is my only copy of this music beyond the original CDs. I was also anal enough to rip them using the paranoid mode of EAC, so we're talking about 4 hours per CD to rip. So a backup and restore utility is useful here, in addition to the point in time when I want to upgrade my hard drive, I want to be able to move everything out, and back in. I don't give a rat's ass if I could actually *play* the music that is backed out, but I need to be able to play them when backed back in.

Calvin