Development Schedule (2.0)
Posted by: rob
Development Schedule (2.0) - 28/07/2001 05:54
It's time for an update on the next software release.
First, it's not going to be called 1.1 after all - it will be release 2.0. There are a number of reasons for this, including there being a lot of new functionality, and avoiding potential confusion with the 1.0x branch.
Although Alpha testers have had the new software for several months, we have not been fully focussed on it for much of that time. This has been due to settling in as a division of a new company, and to a greater extent because of our comittments to the development of other products. You'll hear about those other projects soon, but I do apologise for the delay in car player development.
The good news is that from early August thru Q2 2002 we will be working almost exclusively on the car player software. The first priority is to finalise the spec for 2.0, complete alpha testing, and get a public beta released as soon as possible. In practice we believe that beta will become available at the end of September - I'll refine the date as the alpha phase progresses.
At the same time - and independently of the 2.0 schedule - we are reopening the voice recognition project. You may recall that we recently recruited John Graley, who joined us from the application team at ARM, and his priority is to progress this area of functionality. We'll update on this from time to time.
After 2.0 we have a number of exciting ideas including a revisit of the UI, but I'm going to hold back the teasers for another time
Rob
Posted by: edwin
Re: Development Schedule (2.0) - 28/07/2001 06:13
How nice that you are sharing your development schedule with us, it is indeed very good news!
I guess you will not release the v1.1 alpha (out for a while) as a pre-beta 2.0 then, will you? However, I would love to install it for just the extra visuals only!
Edwin de Vaan
mk2 rev.7 # 080000263 (queue 1232) 6+20Gb blue/red
Posted by: DarkStorm
Re: Development Schedule (2.0) - 28/07/2001 11:39
Make that two of us.
Maybe you guys could release alpha releases as well after one would sign an online waiver or something stating no liability.
That way we could see how the softwares progressing and you guys wouldn't be hounded with "when is it coming", "where are you in development", etc, etc.
Steve
Posted by: rob
Re: Development Schedule (2.0) - 28/07/2001 12:47
> Maybe you guys could release alpha releases as well after one would sign an online waiver
That's not going to happen. As soon as a build is considered "safe" then a public beta is released. If we get through 4 or 5 betas before a consumer release - and if you guys want to download them - then we're happy to let you have them.
We're not happy to let you have Alphas, for a number of reasons, primarily that during intensive testing periods there are new releases almost daily (and we don't have the bandwidth for 1000 people to get them every day, even if you were willing to do so) and those releases sometimes have serious bugs.
As an example, earlier in the alpha phase of 2.0 we discovered a bug which would scrap all of your music after synchronising a certain number of times. Luckily we caught it after the first couple of reports - alpha testers are well aware of the risks, but others may not be.
Finally, alpha testers get to see things which have not been announced. They are under NDA for this purpose. Sometimes the code they test (new CODECs for example) is under a development licence and cannot be distributed more widely.
So, sorry folks, but most of you will have to wait for 2.0-beta1.
Rob
Posted by: tfabris
Re: Development Schedule (2.0) - 28/07/2001 13:03
As an example, earlier in the alpha phase of 2.0 we discovered a bug which would scrap all of your music after synchronising a certain number of times.
Yeah, wasn't I one of the ones who got bitten by this one?
Heh, you guys oughta be glad Empeg doesn't do publc alphas.
Finally, alpha testers get to see things which have not been announced. They are under NDA for this purpose.
And, of course, there's the painful initiation rituals, too.
________________________________
Thank you sir, may I have another!
Posted by: Geoff
Re: Development Schedule (2.0) - 28/07/2001 18:18
In reply to:
And, of course, there's the painful initiation rituals, too
Personally speaking, I'm more than familiar with bizarre initiation rituals, painful or otherwise
but I bet that isn't enough
So I guess I'll wait....
...Hugo's hint about the tuner availability cheered me up no end though
Geoff
---- -------
Got one of the first Mark 2 empegs...
Posted by: DarkStorm
Re: Development Schedule (2.0) - 28/07/2001 23:11
Well it was just a thought. I'm sure their are a few of us out here that would like to be a part of alpha testing, but I guess I'll wait since I don't really have any other choice.
Posted by: pgrzelak
Re: Development Schedule (2.0) - 29/07/2001 16:42
Greetings!
Trust me, I can wait. It has taken me almost 4 days at 24 hours a day in order to reload the empeg after the disk upgrade. I would queue up about 10 GB worth, the most space I can scrounge on my local hard drives, and set it up to run overnight. The last thing I would want is something to blow away the music partitions. But I would like a nice, easy to use, built in backup system as part of emplode...
Paul G.
SN# 090000587 (96GB Smoke)
Posted by: Taym
Re: Development Schedule (2.0) - 29/07/2001 16:49
So would I. Believe me, the more I use empeg, the more I love it. And the more I miss such a backup feature. Anything that can save the files AND the database in the empeg in case of failure of the empeg hdd would just be great. I am spending so much time in entering all the info in all my mp3s, and the empeg is slowly becoming a extraordinaru music database. Year, genre, Comments, Version... Just amazing. Now, the simple idea of a hdd crash a nightmare for me...
Taym
_________________________
MK II BLUE/RED 12GB #923
Posted by: tanstaafl.
Re: Development Schedule (2.0) - 30/07/2001 00:05
But I would like a nice, easy to use, built in backup system as part of emplode...
My absolute #1 priority on the Wish List. It need be no more sophisticated than an icon I can click on in Emplode that will creat a single large TAR file on my PC's hard drive or a network drive. This file need not be readable, editable, playable, or usable in any fashion whatsoever other than to have the capability of being copied back into the same empeg that created it (serial number check?) to do a full restoration after a hard drive crash. This restricted backup capability should alleviate any fears of Rio enabling music piracy.
tanstaafl.
"There Ain't No Such Thing As A Free Lunch"
Posted by: rob
Re: Development Schedule (2.0) - 30/07/2001 03:13
I'm astounded that it has taken so long for someone to start working on what should be a relatively simple project to accommodate certain requirements that Rio are unable to satisfy for reasons of their own. It looks like somebody has finally begun such a project.
Of course I couldn't possibily approve, but it's open source so what can we do eh?
Rob
Posted by: Taym
Re: Development Schedule (2.0) - 30/07/2001 15:00
Right right right!
The single large TAR file is simple and great., That's what I suggested as soon as I entered this crazy great BBS, and, as I said before, the backup does not have to be readable, playable, etc. (Again, some smart immoral hacker may find a way to turn the TAR/RAR/ZIP archive in anything he/she wants, but that's another story, right? ;))
But we need the backup!
Taym
_________________________
MK II BLUE/RED 12GB #923
Posted by: tfabris
Re: Development Schedule (2.0) - 30/07/2001 15:15
You guys don't seem to take a hint. I don't think Empeg can write that backup utility for various reasons.
There's a project in the programming forum that allows you to grab files off the unit via Ethernet, and EmpegTaxi does the same thing, except via USB.
In both cases, they do their work one file at a time. But with a small bit of work, they could both be made into full-fledged backup utilities that don't require modification of the installed software.
The only thing is that I would like them to back up the database information, too. I think that's pretty do-able, too.
So, guys, wanna modify your utilities into backup programs?
___________
Tony Fabris
Posted by: Jazzwire
Re: Development Schedule (2.0) - 30/07/2001 15:22
Part of the changes to the Alpha 7 version of empegTaxi were to add multiple file download support. (It's not enabled in the UI yet, as it needs more testing)
However before making it a full backup utility, I need a checksum routine on the empeg to ensure the files transfered correctly.
Watch this space....
(anyone recommend a good c++ book?)
Jazz
(List 112, Mk2 12 gig #40. Mk1 4 gig #30. Mk3 1.6 16v)
Posted by: tfabris
Re: Development Schedule (2.0) - 30/07/2001 15:32
Regarding checksums:
One thing that has come up in Alpha testing is that the empeg guys sometimes ask me if I have the correct file based on an MD5 checksum of a given file. There is open-source stuff on how to generate an MD5 checksum on PC files. If the empeg itself came with an MD5er built-in to the developer software, that would solve your problem.
Is there an MD5 checksum generator on the developer image?
___________
Tony Fabris
Posted by: Jazzwire
Re: Development Schedule (2.0) - 30/07/2001 15:37
I can't find any MD5 program on my empeg... =(
However, that's the sort of idea I had in mind...
Jazz
(List 112, Mk2 12 gig #40. Mk1 4 gig #30. Mk3 1.6 16v)
Posted by: msaeger
Re: Development Schedule (2.0) - 30/07/2001 15:38
you mean the one like they would be sued by the horrible recording companies of america
would someone unrelated to sonic blue writing a backup utility prevent that from happening in this society of too many lawyers and not enough logic I doubt it
32Gig MK2 In 2001 VW Golf TDI
Posted by: smu
Re: Development Schedule (2.0) - 30/07/2001 15:40
Hi.
I'm not sure wether the md5sum binary is part of the developer image, but a binary can be found in the
tools-binary-empeg-1.0.3.tgz file on my
homepage (preview).
cu,
sven
proud MkII owner (12GB
blue/
green/smoked, #080000113)
Posted by: tfabris
Re: Development Schedule (2.0) - 30/07/2001 15:44
If it's not included in the default developer image, it's probably not what Jazzwire's interested in. I think the idea of EmpegTaxi is for it to work without adding software to the player.
What other options are there for generating a checksum at the command line on the player?
___________
Tony Fabris
Posted by: Taym
Re: Development Schedule (2.0) - 30/07/2001 15:44
Tony, sure we didn't? Of course we took the hint. I think we all read the legal issues involved in the backup thing, and we all understand Rob's point of view ;) The reason why I said we need a backup, leavig my joke about the evil hacker apart :), is exaclty what you pointed out, that is: no current project of feature or third party sw allows a real backup. The empeg info database is left out. So I am doing exactly what you're doing: encourage anyone of the great people in here who has time and capability to make a good complete backup sw for the empeg. :) And of course to them goes my thank you! :)
Taym
_________________________
MK II BLUE/RED 12GB #923
Posted by: tanstaafl.
Re: Development Schedule (2.0) - 30/07/2001 19:05
Of course I couldn't possibily approve...
Really, seriously... would piracy be an issue if the software were written as I described: produce a single large file, unreadable, uneditable, unplayable, flagged so it could only restore to the same empeg that wrote it? You could encrypt the file header, using the empeg's serial number as the decryption key. (Is that serial number hard-wired in the empeg?)
From my position of invincible ignorance, it seems like this should be an easy hurdle to cross.
tanstaafl.
"There Ain't No Such Thing As A Free Lunch"
Posted by: tfabris
Re: Development Schedule (2.0) - 30/07/2001 23:13
Really, seriously... would piracy be an issue if the software were written as I described?
Maybe, or maybe not. But mainly, I think that the Rio folks aren't interested in becoming a "test case".
Here's my take on it (correct me if I'm wrong):
Making a copy of the music files is what would make the RIAA angry. Whether or not those files are stored in an encrypted format probably has nothing to do with it. The fact is, a backup is a copy. And although there are some rules regarding allowable backups of computer software, there are no such rules protecting digital copies of music CDs.
The only rules about copying music CDs are those outlined by the AHRA. If it's a digital copy, it has to implement SCMS. And SCMS has a very specific set of standards-- an encrypted tarball isn't part of the SCMS spec.
The only reason you can get away with doing the same thing on your PC is because PC's are specifically protected by the AHRA. The RIAA would probably like to see that changed very much, but here's my point: By the letter of the AHRA law, Rio can't allow the Empeg Car to make backup copies unless they specifically and exactly implement SCMS. It's this same "letter of the law" that allows audio-extracting CD-ROM drives to exist at all. So you can't have your cake and eat it, too.
I'm sure the Rio people have thought this through very carefully. They know how to implement SCMS, but trust me, you don't WANT them to have to implement it on the car player.
___________
Tony Fabris
Posted by: Captain_Chaos
Re: Development Schedule (2.0) - 31/07/2001 00:31
This functionality is already in displayserver. There's a 'System Backup' link on its homepage which when clicked produces one huge tar file of the entire contents of the empeg. One could use wget or some such utility to automatically download the file without having to use a browser.
Posted by: tanstaafl.
Re: Development Schedule (2.0) - 31/07/2001 01:09
The only reason you can get away with doing the same thing on your PC is because PC's are specifically protected by the AHRA.
But that's the point -- the backup copy would be made to and kept on the PC. Or am I misunderstanding something here?
tanstaafl.
"There Ain't No Such Thing As A Free Lunch"
Posted by: tanstaafl.
Re: Development Schedule (2.0) - 31/07/2001 01:19
This functionality is already in displayserver.
Call me a wimp and a weenie... but I don't want to deal with the hassles involved with a non-standard kernal.
I'm not sure, but I think displayserver does not save the database file. Correct me if I'm wrong, please.
Also, displayserver requires some hoop jumping -- export to a csv file, use that as an "index" for retrieving the song files, something like that. I just want to hook up my USB cable, click an icon on my desktop, and walk away and leave it running overnight and come back the next morning and know that my data files and song files are safe.
Finally, I think the "4 GB bug" is still unresolved -- where the transfer stalls after about 4 GB.
I don't need to extract songs from my empeg (Jazzwire's EmpegTaxi will do that). I just want the ability to create a disaster-recovery file that will leave me "whole" when (not if) my hard drive finally craters.
tanstaafl.
"There Ain't No Such Thing As A Free Lunch"
Posted by: Geoff
Re: Development Schedule (2.0) - 31/07/2001 02:17
Am I correct in assuming the AHRA is an American law?
If so, then someone outside the US could write a nifty empeg backup utility, and providing they don't travel to, say, Florida to give a talk on, say, 'empeg backups: Theory and practice', then there's no chance of them being thrown in the slammer for it.
Is that about right?
Geoff
---- -------
Got one of the first Mark 2 empegs...
Posted by: _hardcore_
Re: Development Schedule (2.0) - 31/07/2001 03:07
Hi,
Untill only a few month back, it was restricted by law in Denmark to copy any digital media. E.g. I couldn't legally make a spare copy of my audio cd, or copy my cd onto a tape to play it in the car (yes, currectly - i only have a tape player in my car, because i still like to listen to radio.) Atleast now they changed to law so that digital copying is legal for private use. But what i'm saying is that there is probably a lot of local rules that requires a great deal of work for the rio/empeg guys to read into, or deny selling in some contries.
Regards,
Kaare
Regards,
Kaare.
Mark II - S/N: 702
Posted by: tigloo
Re: Development Schedule (2.0) - 31/07/2001 03:33
Copies of software and audio files for private purposes are legal in Germany, too. You are just not allowed to sell them or make them available to foreigners. Sharing with friends for private purposes is ok, though.
Also, copying _any_ data for backup purposes is legal in Germany. So creating such a tool here (or in any other European country, I think they're trying to align the laws now) should be safe.
Till
Posted by: peter
Re: Development Schedule (2.0) - 31/07/2001 04:06
I'm not sure, but I think displayserver does not save the database file. Correct me if I'm wrong, please.
The database files are created from the *1 files and contain no extra information -- they serve only to speed up access. An emplode sync causes them to be rebuilt from scratch.
Peter
Posted by: bonzi
Re: Development Schedule (2.0) - 31/07/2001 05:21
If it's not included in the default developer image, it's probably not what Jazzwire's interested in. I think the idea of EmpegTaxi is for it to work without adding software to the player.
What other options are there for generating a checksum at the command line on the player?
sum, cksum... none of which is there by default. If idea is to command the player to send a FID, then I don't see what can we do (except to rely on heavy error checking transfer routine is supposedly doing). If, however, we can execute a script on empeg, then perhaps tar with one of compression options could do.
Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green
Posted by: jwtadmin
Re: Development Schedule (2.0) - 31/07/2001 05:49
Here's a thought for the backup utility.
Why not just dump the entire raw disk using dd to stream out to the usb port to a listener waiting for the stream?
I'm not sure about check suming or error checking, but it seems to me that this would get everything.
To restore you could just reverse the process.
Posted by: djc
Re: Development Schedule (2.0) - 31/07/2001 06:16
good idea, but with a couple of hitches. dd will make an image of the entire drive, whether it contains music or not. a backup of a nearly empty 30GB empeg will still be 30GB in size (before compression).
also, it locks you into a particular drive size. if you backup your 12GB empeg, and later want to restore on a nifty new 48GB drive, you'll still be left with a 12GB partition map after the restore.
i think a file-by-file approach is the way to go.
--dan.
Posted by: smu
Re: Development Schedule (2.0) - 31/07/2001 06:46
Copies of software and audio files for private purposes are legal in Germany, too. You are just not allowed to sell them or make them available to foreigners. Sharing with friends for private purposes is ok, though.
WAIT. We have to differentiate this a little:
- It is legal to copy audio for private purpose. The media you copy from must be either your property or being lent to you. You can only copy for your purpose, you are not allowed to make copies you intend to give away as a present or that you intend to sell. There are two szenarios that effectively do the same, but one is legal while the other is illegal: You own a CD, make a copy of it and give that copy to a friend as a gift. This is illegal. Now, you lend that CD to your friend, give him an empty CD-R as a gift, he gives you the CD and the CD-R and asks you to copy it for him (note, he doesn't give the CD back to you, he only gives it to you for the sole purpose if making a copy). I don't know the english words for it, but the difference is that while the CD always is (and well be) your property ("Eigentum",i.e. you own it), he still has it ("Besitz", it is part of his possesion) in legal terms. After you made the copy, you give the CD and the (now written to) CD-R to him. He can now give the CD back to you (and thereby end the loan of it). This procedure is legal (though effectively doing the same thing as the easier procedure of just copying the CD and giving it away). Weird, isn't it?
- Software is a whole different thing. It is legal to make backups (no matter what the product license says), that is you may make any number of copies of a software you own, but you are still limited to use only as many copies of it (at the same time) as you have licenses to do so (you are not limited in the nummber of private audio copies or the use of these). You are never allowed to make a copy of a software you don't own (such as your friend's MS Office), and of course you are not allowed to use one of his backups. The copyright holder of the software may make excempts, as it is done with GPL and other public domain software, or even limited excempts, such as done for shareware. Oh, no law exists that limits your choice of backup media, so you might even be safe if you put your backups on the internet, as long as you make certain that those backups are not used by anyone else.
Just to confuse you all some more.
cu,
sven
proud MkII owner (12GB
blue/
green/smoked, #080000113)
Posted by: tigloo
Re: Development Schedule (2.0) - 31/07/2001 06:59
I was assuming that that you own the CD, because the other scenario (while maybe legal) sounds like a strange situation to me which forcefully tries to get around the law.
At least I'd consider it weird that a friend would borrow my Empeg just to give it back to me to make a backup of its contents. :) All I want is a private copy of its contents (and since I own the contents anyway .... but that's a different story :) )
Till
Posted by: tfabris
Re: Development Schedule (2.0) - 31/07/2001 10:45
A couple of minor corrections:
1) Displayserver doesn't require a nonstandard kernel for the backup thingy to work. It'll work with the standard kernel. You do have to install displayserver onto the empeg's hard disk and run it, though.
2) Displayserver does not require a CSV export.
3) I don't know if Displayserver backs up only the song files, or if it backs up the *1 database files, too. If it does, then it really is a full backup utility.
___________
Tony Fabris
Posted by: tfabris
Re: Development Schedule (2.0) - 31/07/2001 10:48
Posted by: tfabris
Re: Development Schedule (2.0) - 31/07/2001 10:49
and providing they don't travel to, say, Florida to give a talk on, say, 'empeg backups: Theory and practice'
ROFL !!!!
I don't know how many people got that reference, but damn, that was funny.
___________
Tony Fabris
Posted by: tfabris
Re: Development Schedule (2.0) - 31/07/2001 10:53
But that's the point -- the backup copy would be made to and kept on the PC. Or am I misunderstanding something here?
Yeah- that the empeg (the source device for the copy) is not a PC. It is classified as a digital music player, not as a PC. By allowing it to copy the files, it would become a non-PC digital music copying device, and as such, would require SCMS implementation to comply with the letter of the AHRA law.
___________
Tony Fabris
Posted by: phaigh
Re: Development Schedule (2.0) - 31/07/2001 13:32
Thanks for being transparant about your plans about the software.
I know that most people will appreciate gestures like this.
Cheers,
Paul.
Paul Haigh, Reg. 4120
(mk1) 6GB, Blue, 00254
(mk2) 12GB, Red, 00357
Posted by: bmiller
Re: Development Schedule (2.0) - 31/07/2001 13:35
I don't mean to be nit picky and I hope I don't get flamed but I wanted to raise this.
With my Rio600, I'm pretty sure i can copy a song to it and on a different computer copy the song back down.
Am I missing something here?
Posted by: tfabris
Re: Development Schedule (2.0) - 31/07/2001 13:39
With my Rio600, I'm pretty sure i can copy a song to it and on a different computer copy the song back down.
If I understand Rio's position on this, you shouldn't be able to do it with the software Rio provides. Maybe with third-party software, but not "out of the box". That would be the same position the Empeg is in right now.
I don't own a Rio600, so I can't check. Why don't you double-check that one and get back to us?
___________
Tony Fabris
Posted by: gbeer
Re: Development Schedule (2.0) - 31/07/2001 21:44
...you can get away with doing the same thing on your PC is because PC's are specifically protected by the AHRA.
A couple of questions related to the above.
Could this be why some companies are billing their units as AutoPC's?
Dose the AHRA contain a definition of what constitutes a PC?
I can't think of a single characteristic of the empeg that could be used to declassify it as a pc. Not without that same characteristic being found in machines that are undeniably PC's. No kbd, no display, think about rack mount servers. No IP address, HA! Size, my Handspring is smaller, faster and has more storage than the original IBM PC. Actually I think the empeg would outperform that old IBM too.
Enough beating around the penguin. Why doesn't that PC exclusion in the AHRA apply the the Empeg?
--Glenn
Posted by: time
Re: Development Schedule (2.0) - 31/07/2001 23:20
That is correct. With the out of the box software it is a one-way trip for music. On the Rio800, which has a microphone, you are enabled to off load recorded files, but that is all.
I believe there are some third party applications for pulling files off, but none that come from Rio.
Best regards,
Tim
Posted by: rob
Re: Development Schedule (2.0) - 01/08/2001 04:30
It has to do with the primary purpose for which the product is sold. This will relate to the out-of-the-box functionality, placement within stores, marketing approach and so forth. Like most legislation, the implementation is somewhat open to interpretation.
Rob
Posted by: tfabris
Re: Development Schedule (2.0) - 01/08/2001 09:49
To answer your AHRA questions,
here is the full text, as well as
one interpretation of it.
___________
Tony Fabris
Posted by: DWallach
Re: Development Schedule (2.0) - 02/08/2001 20:08
It's important to point out that empeg have taken certain measures that make it difficult for you extract files from the empeg car player. There's another U.S. law called the Digital Millenium Copyright Act that
criminalizes the creation of "circumvention" devices. How this law applies to the situation of "backing up" files on an empeg is largely open to dispute because there really isn't sufficient case law (i.e., judicial verdicts that interpret the DMCA). The EU has a similar law on the books that's, so I've heard, even
more draconian than the US law (and don't ask me how the EU parliamentary system interoperates with national laws of EU countries).
In short, given the current twisted technical and legal quagmire that is sometimes called "digital rights managment", it's quite understandable why empeg ships their product as they do. Until things settle out, including
the lawsuit where I'm one of the plaintiffs, it would be inadvisable for a third-party to build software to "circumvent" the mechanisms built into an empeg.
Posted by: phat_slug
Re: Development Schedule (2.0) - 02/08/2001 23:44
Then tell me why isnt this any issue with my Archos MP3 player ??
/It has to do with the primary purpose for which the product is sold. This will relate to the out-of-the-box functionality, placement within stores, marketing approach and so forth. Like most legislation, the implementation is somewhat open to interpretation. /
Posted by: tfabris
Re: Development Schedule (2.0) - 03/08/2001 01:16
Then tell me why isnt this any issue with my Archos MP3 player ??
I've never heard of that product. Perhaps it's not an issue because that one is small enough to fly under the RIAA-dar?
___________
Tony Fabris
Posted by: Captain_Chaos
Re: Development Schedule (2.0) - 04/08/2001 07:04
Call me a wimp and a weenie... but I don't want to deal with the hassles involved with a non-standard kernal.
You don't need a non-standard kernel for displayserver, just the developer image (so you can install it). You only need the kernel patch if you want to control the empeg remotely through displayserver (and some other IR related applications), but displayserver works fine without it.
I'm not sure, but I think displayserver does not save the database file. Correct me if I'm wrong, please.
Also, displayserver requires some hoop jumping -- export to a csv file, use that as an "index" for retrieving the song files, something like that. I just want to hook up my USB cable, click an icon on my desktop, and walk away and leave it running overnight and come back the next morning and know that my data files and song files are safe.
I'm not talking about downloading the songs one by one, I'm talking about displayserver's separate backup mechanism (which you'll see if you read my previous message carefully). There's a 'System backup' link on displayserver's homepage that will land you one giant tar file with the entire contents of the music partitions, including all songs and database files.
Posted by: BartDG
Re: Development Schedule (2.0) - 04/08/2001 15:22
"Then tell me why isnt this any issue with my Archos MP3 player ??
I've never heard of that product. Perhaps it's not an issue because that one is small enough to fly under the RIAA-dar?"
The Archos is one of the most popular MP3 portable players, together with SSI's Neo Jukebox.
It uses a notebook harddrive (like creative's Nomad), but it's not limited to 6gig (I know, the Nomad isn't either, with some tweaking, but the Archos doesn't get painfully slow when it's HD gets upgraded)
More info on it here :http://www.archos.com/uk/default.html
and here : http://www2.funmp3players.com/
If I was in the market for a portable MP3 player, this would probably be the one I would buy.
Posted by: rob
Re: Development Schedule (2.0) - 06/08/2001 05:40
The Archos is one of the most popular MP3 portable players, together with SSI's Neo Jukebox
Neither of them are close to being the most popular MP3 portable player (in terms of sales volume). If you're talking specifically about hard disk portables, then you could perhaps make that statement since there are only a few products on the market right now. Last I heard, Creative were in the lead by a large margin.
Rob