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... :)