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

I didn't set up the tags right. :-P Even if I did, It's taken me considerable time to rip the music and encode it. The empeg is the sole repository of that, so a backup and restore utility is still needed.

Calvin

How about as a step 1, music only?

Version 2 can back up the rest.

Calvin

No, the protocol doesn't let you get arbitrary files.

I would assume that you probably copied your custom /sbin/init onto the player from a PC, though, and didn't edit it on the unit itself :)

You can get to the EQ settings (etc) though, I believe.

Hugo

How about as a step 1, music only?

Version 2 can back up the rest.

Point being that you don't need step 1 as there are already tools that do that (jemplode, displayserver, ftp, etc). It is the rest of the stuff that nobody seems to want to write a utility to get.

-Mike

I would assume that you probably copied your custom /sbin/init onto the player from a PC, though, and didn't edit it on the unit itself :)

Of course, and I also have copies of all my mp3s on the same computer with tags setup exactly the same as they are on the empeg. This is why I am the one who does not understand why so many people seem to think a backup tool is necessary :-) I was just doubting that the protocol would let you do the full backup that some people are requesting.

-Mike

I didn't set up the tags right. :-P Even if I did, It's taken me considerable time to rip the music and encode it. The empeg is the sole repository of that, so a backup and restore utility is still needed.

OK, so for arguments sake here is what I would do if I was in that situation....

1. Use ftp to copy all of the fids (mp3 and data) from the empeg.
2. Write a perl script to parse the data fids and apply the data to ID3 tags in the mp3s. This is pretty easy to do since the data and music fids are named the same except for one digit. There are a few perl modules that make id3 tagging from a perl script trivial.
3. Use one of the many existing "tag and rename" programs to rename all of the mp3s based on the tag info you just added.

You now have a copy of what is on your empeg with all of the ID3 tags appropriately set. From now on whenever you add a new mp3 make sure it is tagged appropriately and add it to the empeg and your new mp3 archive on your computer so you don't have to do this again. The perl script for this is easy to write, I already have one that I use for tagging my mp3s that has 90% of the needed functionality. But, this is not a process that your average user is going to be comfortable with which is why everyone tells new empeg owners to spend a lot of time setting up their tags.

-Mike

Hi.

But, this is not a process that your average user is going to be comfortable with which is why everyone tells new empeg owners to spend a lot of time setting up their tags.

For me, tags aren't the main problem. I have more problems with

a) custom playlists in addition to the album/artist ones, like 

   playlists for different moods (dreaming, aggressive etc.)

b) my modifications to config.ini

Especially the first one took weeks to set up correctly, so I wouldn't like to loose that. Also backing up equalizer settings, wendy filters and things like that would be nice even if I don't use them currently.
Damn, if I understood the emptool sources any better than I do, I would surely try to write a backup/restore utility for linux and/or windows (commandline only in any case though).

cu,
sven.

Yup, I tried backup with JEmplode - seems to be working fine. I don't remember, though, what is it doing with multiply-linked tunes...

We still need backup/restore mechanism for thing kept on that raw partition (EQ setings etc). There's also that neat idea of grabbing a bookmark and converting it to playlist - perhaps Mark could add a service or two in kernel for that and JEmplode guys would then use them, add UI etc?

Hmmm, JEmplode works with whatever services player app provides, right (even for screen grabbing?) So, in order to have some other player-side services, we still need an easy protocol to access them. Kernel httpd sounds reasonable.

Just my 0.16 kn at the current exchange rate...

The chances of not trashing data while testing such a beast are fairly small.

...but since 'manually' backing up and restoring everything via ftp is trivial (togethet with that partition - just dd it), I don't think that this danger is what keeps developers from making a better mousetrap.

If you have 20Gb or so of data (as I'm sure most of us do) then backuping it up and restoring it via ftp over a 10Mb network interface could never be described as trivial I'm afraid. Even if it happened at theoretical max speed, backing up and restoring that amount of data would take 11 hours or so.

Even dd'ing it, assuming you have drive space available is a very slow process.

We recently got the go-ahead to allow emplode to download tracks from the car player back to the PC. The basic functionality is already implemented and will be included in a forthcoming release.

To start with we will not claim that this is a complete backup solution, because it will not update the ID3 tags or save the playlist structure. That will probably happen in a later version - but it's a start.

Rob

Nights are long...

Excellent news Rob. Do we also get the ability to upload non-MP3 files back again soon ?

[Tenting fingers in Monty Burns style]

Eeeeeeexcellent...

Why the change of heart? Is the EOL'ed Empeg/RioCar now low profile enough that nobody will notice any copyright issues? Or have the laws been relaxed?

I think the change of heart is more due to the recent comments/sort of announcement about the new product which as we all recall uses the same base software [at source level, if not binary level] as the Empeg does now.
So this feature will be in the code set for this product and also available to Empeg owners.

I also think you can assume if there is any relaxing of attitudes to the RIAA and others its most probably due to the fact that 1 more lawsuit won't much bother SB much given that they offer the same share and enjoyTM features in the ReplayTV 4000 right now.

That's not quite true. The new product will not have this feature, but the extensive research that was carried out to arrive at that decision showed up that the car player can have it.

Rob

Yes, although not until after the current version has completed beta testing.

Rob

don,t take me the wrong way Rob, I applaud 100% your decision to implment this feature in the software - even if the new product won't offer it [yet].

I guess now you are protected by SB legals department you don't have to be so cautious with regard to the likes of the RIAA as you were when you were EMPEG Ltd right?
Having a lawsuit hanging over your head when you were a small UK company would have been the kiss of death for the empeg product so it was a sensible move at the time to prevent the emplode software from being able to upload back to the PC.

I guess now you are protected by SB legals department you don't have to be so cautious with regard to the likes of the RIAA as you were when you were EMPEG Ltd right?

No, they have to be just as cautious. The difference is that the SB legal department are the ones who worry about now, not the engineers.

Dunno what I'm going to say in the FAQ now!

Oh goody does this mean we are going to get a file taxi type thing

I certainly hope so!

THIS is GREAT news, Rob! Thank you!
IMHO you should give maximum precedence to the backup feature even over the many other interesting features being included in the next releases. Personally, this is definitely the most important, in my priority list.

Interesting... I don't suppose a similar change of heart would allow you guys to let the empeg boot directly into visual mode in the car now that the product has been EOL'd (maybe via a config.ini option so it still took user intervention)?

-Mike

Of course, and I also have copies of all my mp3s on the same computer with tags setup exactly the same as they are on the empeg. This is why I am the one who does not understand why so many people seem to think a backup tool is necessary :-)

Yes, and I also have the original CDs and installation disks for all of the software on my computer. So why do I bother keeping a fully bootable mirror copy of my C drive on another hard drive?

Because it's a whole lot easier to just use Drive Image to recreate my C: drive after a disaster than it is to reformat the disk, install an operating system, install and configure my software one program at a time, recover the data from whatever backups I had.... 40 minutes of work instead of several weeks. Same goes for the empeg. I don't want to have to reload all of my songs, re-create all of my playlists, try to find and correct all the database errors that I have already found and fixed once already, try and figure out which songs are on my home computer, which songs are on my work computer, etc.

I have said this so many times I am thinking of putting it into a keyboard macro so I can keep saying it with just a single keystroke: "I want a Windows backup utility that, with a single keystroke or icon click will create a complete mirror copy of my empeg onto a local hard drive, without the use of non-standard kernals or third party player applications. The backup doesn't have to be readable, writable, editable, playable, or usable for any damn thing in the world except for one: I want to be able to copy it back into my empeg and have a complete restoration in the event of a system failure. If piracy is a concern, write the software so that it can only write the data back into the same empeg (serial # check?) that wrote it."

I would be quite willing to pay for this software, and suspect that I am not alone in this. Not all of us have Linux computers, or are conversant with FTP, or have the ability to put together a perl script or the like. I just want a "Backup Utility for the Compleat Idiot".

Please?

tanstaafl.

Do you run drive image every night? Does it copy everything or just the things that changed since the last time it was run? Im about to reformat my computer, and was considering using a raid array to have a mirror backup, but am not sure what is the better solution.

Sean

No

Rob

I strongly suspect Hijack will implement this in the not too distant future..

-ml

Mmm.. okay, I suppose some folks might want that.

But for me it would be totally impractical to have MicroSoft hosted image backup/restore.

(1) I don't run MicroSoft products, except for Emplode inside VMWare under Linux.

(2) Image backup of my 18GB player would take about 12 hours (assuming 30% efficiency at 10mbs over ethernet). For folks with large collections the number would be much higher.

I suppose a smarter incremental solution could be good, backing up only that which has changed.

But best of all is still to just keep the music collection on the host system in the first place, and backup the playlists from Emplode (can it re-import CSV playlists?). But as folks customize their players more and more, a full filesystem backup (with increments) begins to look better..

"I suppose a smarter incremental solution could be good, backing up only that which has changed."

Exactly.


"But best of all is still to just keep the music collection on the host system in the first place, and backup the playlists from Emplode (can it re-import CSV playlists?)."

I have this setup for the most part, but at the moment, the csv file is export only. I can rebuild all my album playlists simply by dragging and dropping, but all the mood and mix playlists would be lost.

But best of all is still to just keep the music collection on the host system in the first place, and backup the playlists from Emplode (can it re-import CSV playlists?). But as folks customize their players more and more, a full filesystem backup (with increments) begins to look better..


This is exactly what I want. My main priority would be a system for backing up the playlist and preference structures and not the actual music. It's easy enough to FTP the music if you need to. I keep a copy of all my tagged MP3 files on a 60GB desktop drive - but custom edits to playlists in emplode can take a long time to duplicate. And that's provided you can even rememeber exactly how you had everything set up to begin with.

Emplode cannot currently (as of B3) import CSV (from what I've seen in the program and read online).

My ideal solution would be a local/remote sync operation that would allow you to have two copies of your music (and database) - one on the empeg and the other on whatever computer. Hopefulyl being able to run emplode without the empeg, making changes and saving them for a later sync operation. At the same time I would love for emplode to support modifying ID3 tags - it offers batch capabilities with its soup and playlist views that simply are impractical or not available with any other software I've tried.

Currently any changes I make in emplode to correct tags, I have to re-apply to my original MP3 files with Tag Studio or similar (and Tag studio, though it can do batch, only works with simple directory structures, it can't group files based on any internal tag criteria).

Bruno

Damn, I'm still at work and it's nearly 11pm... :)

Do you run drive image every night? Does it copy everything or just the things that changed since the last time it was run?

I only run it when the thought hits me that I haven't done backup in a long time. I don't have any mission critical data on my home computer, so every couple of weeks is often enough.

I have it set up to just recreate the entire C: drive partition on my D: drive, rather than try and get fancy and use it as a backup utility with incremental capabilities. I think (not sure) it can be configured to do so if you want, however. It takes surprisingly longer than I thought it would to mirror the partition -- something in excess of two and a half hours, mirroring a 40GB C: drive to an identical 40GB D: drive, but I just let it run unattended overnight so no big deal.

tanstaafl.

Fine, I'll get it to import the XML data . Probably in the new year, though -- we're winding down for Christmas now, and I've got most of this week off now.

As far as keeping two sets of music in sync and mirroring the changes, wait. It's something I'm hacking on in my spare time. When it's ready, I'll release it.

Offline tag editing in emplode is something I'd like to see -- but it won't be ready for v2.0.

Be patient, grasshopper .

Sounds awesome. I don't think I'm going to have too much time for any empeg db maintenance over the holidays anyway. I'm still hoping I'll have the inside of my car fully installed by the new year :)

Bruno