iriver clix - user selectable transfer protocol?

[traut]

Originally Posted by Step666

You have completed missed the point.


The point is not that any transfer protocol will work with any file system, the point is that the user should have some say in it all.

I guess I got the point before. I did not mind for a long time - but since this thread goes on for a while, always sailing under incorrect subject, I finally wanted to point out that UMS vs. MTP is not a question of asking for different file systems.

... and I agree that the user should have a choice. In fact I don't see the need for a choice, since UMS would be god enough for any needs (I don't see any benefit from MTP here) - but it is exactly the way the clix was planned and developed NOT to support UMS, but to offer a tight integration to WMP11 instead. Since MS now builds MP3 players of their own, ignoring their former own standarf of Play For Sure, this may be discussed again - even providing multiple protocols in parallel.

In fact I do not know by now what the actual file system is. I would mind, if it would make any difference to me - and it makes a major difference e.g. for external USB hard drives, where I may use fat32 both on Mac and Win, but it sucks everywhere. I may read but not write NTFS formatted disks on the Mac, while HFS+ is not supported on Win. There are some 3rd party extensions around, which are more or less integrated and up to date.

So I checked by now - the Disk Utility just named File System: Generic or File System : MS-DOS File System

The System Profiler said:
iriver U10:

Capacity: 1.9 GB
Removable Media: Yes
Detachable Drive: Yes
BSD Name: disk3
Vendor Name: iriver Limited
OS9 Drivers: No
Product ID: 4118 ($1016)
Speed: Up to 480 Mb/sec
Bus Power (mA): 500
Serial Number: 6C0F590E0000

So I don't know much about the FS used here, but I guess it's a rather simple fat32.

In fact I was surprised that it did handle file names with 8bit chars very well (maybe UTF-support is supported very well from Korean companies). I tried a filename wit Äöß.txt. But the internal representation of text sucks (I don't need to select from languages here, but from a range of used/supported charsets instead) and does not show the characters I expect.

[clieos]

@truat: you are right, and somewhat wrong.

You are right to point out that the words chosen for the question is 'questionable', but you have to understand the reason is mainly for the benefit of those who are not-so-computer-savvy. In the current world of PC users, how many are there who can actually list down all the major components in their own PC and how many who can tell the major technical differences between an Intel dual cores and an AMD dual cores processor? Asking people what type of transfer protocol they want when they are still calling their PC a 'CPU' will only add more confusion to the mix.

I think the question is wrong but understandable for those who are computer savvy; As for those who are not so computer savvy, the question is less confusing for them.

Sometime, a wrong question can give you the right answer.

[intogamer92]

i like drag and drop =] pretty simple and you dont need to run an external application

[_gmureddu_]

Originally Posted by intogamer92

i like drag and drop =] pretty simple and you dont need to run an external application

The core of the discussion is not if you are able to "drag and drop" as you can do that with both methods of transfering files (transfer protocols), but rather "how does the system see the device", either as a media device or a generic storage device, which for the sake of the discussion are MTP and MSC [UMS] respectively. However, at the [common] user level this poses no "threat" as many people will simply only see that before their players were a L:\ drive and now they refer to it as Clix:\ (from the Explorer's location bar). At any rate, many users will find the second more "convenient" and the first a bit more "cumbersome", however many users have also grown used to the "old" method. At the user level the functionality is virtually the same (provided they use the device within the boundaries it was thought to be used [MTP-compliant media library managers, and players] or through the shell [Explorer]). The point of the discussion is not the idea behind the method used, but the implementation, i.e how iriver and Microsoft have implemented this way of transfering files from your PC to your Clix/[other-MTP-device] and viceversa. At the moment, this last part is what's "flawed", and the reason why a lot of people are asking to be able to have the device "switch" from one to the other, or even make it so that you could set this directly into the firmware's settings (how would you like your device to "talk" to your computer, using MTP or MSC). Thus far the consensus is to have the ability to switch between the two.

[clieos]

Personally speaking, I don't see a problem with MTP vs. UMS(MSC).

I still remember those day which I was piss for buying a USB card so my old PC can use a USB mouse (yep, it is that old), where is the good old PS/2 anymore? How about booting into a true DOS environment instead of the whatever XP/Vista has now? What should I do to my old floppy since only 2% of PC worldwide have a floppy drive?

If MTP has a 'flaw', it is only because it is not popular enough...for now.

[mrleowashingtonii]

I use my old archos to move files and yes you can browse the clix, but you can't unzip directly to it, and it doesn't assign a drive letter, you can't parttion it. So in a nutshell - YES, PLEASE ADD IT !!!!

[cvmartinez]

Originally Posted by Breakdown

I was told that the Sansa e2x0 dual boots into MTP and UMS. If that's true then I think that would be the best of both worlds for the clix too.

I looked at the Sansa e2xxR (Rhapsody version), and they do support both MTP and UMS modes. While I find MTP mode w/ WMP11 to be really good, choice is always better...cuz you just never know.

[slickthug85]

mtp really blows
i dont see n e advantage over ums
but with ums u can use the player as a flash drive on any os
now i gota buy myself another flash drive bcos of this gay mtp thing
n e 1 got a list of advantages that mtp can do that ums cant?

[clieos]

^ try not to get too much txting going. It is really difficult to read.

[_gmureddu_]

Originally Posted by slickthug85

n e 1 got a list of advantages that mtp can do that ums cant?

In concept (until it is ratified as a new USB device class, just like MSC [UMS]), MTP is FAR supperior for the purposes of a media player due to a number of things:

• No overhead to the host computer of controlling another device. It is not much of a burden on current hardware, but it frees the process as it enables a number of other things:
• Independency of filesystem, literally every implementator could use any (and I mean any) filesystem on the device, as the host computer is not responsible for that filesystem, but the DAP's firmware, so this opens the door to having much more robust and better suited filesystems for these devices (for instance, one with journaling to avoid database corruption, better suited to make out the most out of the available space [better block management], faster reads, etc)
• The device and the PC work more like a network connection, like a network share over SMB (Windows shares), where one computer sends a series of commands along with the files to the other computer. The same is the basic principle here, your computer sends a series of commands through this protocol to your device, receives the files, adds metadata to the database, etc, based purely on these commands. The computer is not responsible for anything else than sending these commands, the device is entirely responsible of their execution, and even better, their interpretation and allocation and organization of the files and data structures.
• Gives the ability to better organize how a particular device works, with standard applications, the aim is to get the protocol into a new device class definition, so that any compliant OS and program could send commands to MTP devices just like virutally any OS is able to communicate with one another through the Internet using TCP/IP.
• With those bases, implementers can do pretty much anything. However this greatly depends on the implementation itself (not the protocol as such) and that the protocol gets ratified as a new USB Device Class, so implementation could be even wider.

If you know how does MSC/UMS work, you'll recognize the advantages MTP has over it (for DAP devices, of course).

[slickthug85]

thx for the info
i will look further into this mtp thing
i just think it will be a while untill all the OS' adopt this standard

and i cant really use the clix as a flash drive because my main uses are for uni and they use linux there and i dont have the rights to install/change anything.

and i wanted to be able to use it when i go to librarys and net cafes when they have OS' other than windows xp or dont even have wmp updated.

they shuda made it backwards compatible thats all or not lose flash drive compatibility

[slickthug85]

another question, is it possible to make a firmware that will make it ums now??
i mean like physically possible

if possible whats holding them back from releasing thins firmware. i mean they alredy have that option for the u10. they only probably have to change a few lines of code and everything would be sweet.

did they like make a contract with microsoft that theyr not allowed??

can we somehow direct this to microsoft so they can do sumfing about it??

[Ted Yo!]

If you read the plays for sure requirements, they aren't allowed to provide a menu option like the sansa does. However, there is nothing (that I am aware of) preventing them from releasing seperate firmware.

I have no idea what kind of contract was or wasn't made, but sine MS was involved in the clix development they may be sticking with MTP for good faith.

can we somehow direct this to microsoft so they can do sumfing about it

Don't worry, people from MS read this board just like people from iriver do.

[traut]

Originally Posted by _gmureddu_

In concept (until it is ratified as a new USB device class, just like MSC [UMS]), MTP is FAR supperior for the purposes of a media player due to a number of things:

How much of this concept is used in reality?

[*]No overhead to the host computer of controlling another device. It is not much of a burden on current hardware, but it frees the process as it enables a number of other things:

The overhead is still around, although it's taken over to the PC and protocol layer. Does anyone have some real numbers? How much is the protocol firmware size, e.g. of U10 MTP vs. U10 UMS? How much is the CPU load of UMS vs. MTP?

What's the practical use, as long as you can't use the host U10 while connected to the PC?

... In fact I don't know yet which one of both parts is named as the host here - the Win PC or the audio player? I assumed that your host is the PC, since you named the audio player as a DAP. Concerning your explanations, I'd expect that both would be hosts.

[*]Independency of filesystem, literally every implementator could use any (and I mean any) filesystem on the device, as the host computer is not responsible for that filesystem, but the DAP's firmware, so this opens the door to having much more robust and better suited filesystems for these devices (for instance, one with journaling to avoid database corruption, better suited to make out the most out of the available space [better block management], faster reads, etc)

who cares - as long as you can't use special advantages of a file system, there's no special benefit. Typical applications would rely on default file systems where the MTP stack is around. Optimized solutions would work without a file system at all, but would have dedicated and optimized operations for writing to different storage areas (due to the degradation of flash cells), for redundancy and error correction. This can be done for any transfer protocol.

I guess it's always a topic of the transfer protocol to encapsulate the file system on the host. You say you can't use other file systems via UMS?

[*]The device and the PC work more like a network connection, like a network share over SMB (Windows shares), where one computer sends a series of commands along with the files to the other computer. The same is the basic principle here, your computer sends a series of commands through this protocol to your device, receives the files, adds metadata to the database, etc, based purely on these commands. The computer is not responsible for anything else than sending these commands, the device is entirely responsible of their execution, and even better, their interpretation and allocation and organization of the files and data structures.

This means, that U10 MTP version can work as a player, while connected to the PC? My UMS version can't...

[*]Gives the ability to better organize how a particular device works, with standard applications, the aim is to get the protocol into a new device class definition, so that any compliant OS and program could send commands to MTP devices just like virutally any OS is able to communicate with one another through the Internet using TCP/IP.

This sounds like a major protocol overhead to me. I did not understand why you compared MTP and TCP/IP - I expected the difference is more like MTP and FTP.

[*]With those bases, implementers can do pretty much anything. However this greatly depends on the implementation itself (not the protocol as such) and that the protocol gets ratified as a new USB Device Class, so implementation could be even wider.

So it's a matter of implementation again, whether it's good or bad. Personally, I fell: If functionality is not given directly by taking the proper protocol, but will depend on further implementation, then it's less a matter of the transfer protocol, but of the firmware layer above. The question then is: What's the real blocker, which can't be done by e.g. UMS, which can be done by MTP.

I guess you are much more expert than I am. Maybe you could show how the actual benefits are implemented on the clix, the Zune or any other player, which could not be done via other transfer protocols (or how much more effort it would take to abuse another protocol for these functions).

[_gmureddu_]

Originally Posted by traut

How much of this concept is used in reality?

Ask both Microsoft and iRiver

Originally Posted by traut

The overhead is still around, although it's taken over to the PC and protocol layer. Does anyone have some real numbers? How much is the protocol firmware size, e.g. of U10 MTP vs. U10 UMS? How much is the CPU load of UMS vs. MTP?[

What's the practical use, as long as you can't use the host U10 while connected to the PC?

... In fact I don't know yet which one of both parts is named as the host here - the Win PC or the audio player? I assumed that your host is the PC, since you named the audio player as a DAP. Concerning your explanations, I'd expect that both would be hosts.

I think here the key would be the overhead on the device, as PCs are more than capable of handling them both.

Originally Posted by traut

who cares - as long as you can't use special advantages of a file system, there's no special benefit. Typical applications would rely on default file systems where the MTP stack is around. Optimized solutions would work without a file system at all, but would have dedicated and optimized operations for writing to different storage areas (due to the degradation of flash cells), for redundancy and error correction. This can be done for any transfer protocol.

I guess it's always a topic of the transfer protocol to encapsulate the file system on the host. You say you can't use other file systems via UMS?

Well, for starters different filesystems have different benefits and drawbacks. Just look around and virtually any modern filesystem is ways better than any of the FATs, which are still widely used by these types of applications... Not the best FS you can use on any system, especially when it is so prone to corruption.

And yes, you can use any FS with MSC devices, provided the host OS has the driver for that FS. And since pretty much the only FS that has implementations on vritually any OS is FAT(12,16,32), that's what's mostly used on any kind of external storage. Hell, even some MTP devices use FAT16/32 for their filesystem.

Originally Posted by traut

This means, that U10 MTP version can work as a player, while connected to the PC? My UMS version can't...

Means it could, just as long as the firmware permitted it, in other words, is a problem of implementation.

Originally Posted by traut

This sounds like a major protocol overhead to me. I did not understand why you compared MTP and TCP/IP - I expected the difference is more like MTP and FTP.

FTP uses TCP/IP as its underlying means of communication. And no, it doesn't act like UDP, as (if you are familiar with it) TCP/IP adds some overhead on the line as this protocol ensures all packets go through the line by means of confirmation packets (which in this case is necessary for MTP devices, otherwise, how would you, the user, know if all the files you sent actually got to your DAP?), UDP does not have this overhead, and that's the reason why it is more suited for things like VoIP and gaming. HTTP/FTP/SMB/NFS are all protocols that use TCP/IP as infrastructure.

Originally Posted by traut

So it's a matter of implementation again, whether it's good or bad. Personally, I fell: If functionality is not given directly by taking the proper protocol, but will depend on further implementation, then it's less a matter of the transfer protocol, but of the firmware layer above. The question then is: What's the real blocker, which can't be done by e.g. UMS, which can be done by MTP.

I guess you are much more expert than I am. Maybe you could show how the actual benefits are implemented on the clix, the Zune or any other player, which could not be done via other transfer protocols (or how much more effort it would take to abuse another protocol for these functions).

Yes it all falls under the implementation, ergo the implementer's responsibility.

Actual implementations currently are lacking in one way or another, the main problem for MTP currently is not only how it is implemented, but rather its scarcity and lack of popularity.

The main thing that can be achived with MTP that can't be done with MSC (unless you used specialized apps) is the ability to use common software to perform synchronizations. Even though the protocol is implemented as part of WMP11, you can use other software to perform the synchronization (provided it "speaks" MTP) like WinAmp, MediaMonkey, etc. Yes means that you have to have installed some form of WMP to be able to have the driver... This is bitter-sweet, as now with Vista, all those PCs will have the necessary driver for MTP. That's Microsoft's choice how they implement (yes the darn implementation again) the driver on their platforms, and they've tied the protocol to WMP (not that you "can't get away with it" and install it stand-alone (I just don't know how would you go about that). So with MTP you can use any compliant software to sync, which also means that everything will be held into a metadata database for things like album, art, thumbnails, playlists, artist, title, year, etc, etc, all extracted from the metadata on the files themselves.

[Ted Yo!]

The whole thing really boils down to two things:
1) With MTP the computer does not need to know anything about the database or the file system. You can write software to handle this (like easypmp) but that sort of defeats the purpose of being able to plug it in anywhere and have it work.
2) MTP is purely transaction based - like a database. First there is a call that tells the device to allocate storage and hand back a handle (while also storing metadata), next the file itself is sent. If anything happens in this process the changes are rolled back gracefully. UMS has no way to do this. If anything goes wrong, at best you are left with a file fragment. At worst you have corrupted the file allocation table or the device's database.

The downside is that a bunch of small writes are never as effecient as one larger one. There is extra overhead on every file transfer which takes time. The earlier MTP devices were increadibly slow because they started with a UMS implementation and 'put MTP on top'. Now they are getting to be of decent speed, but a streight UMS implementation will almost always be faster. (To put this in perspective, early MTP devices were around 6Mbps. Now the faster ones are around 55Mbps compaired to UMS based players which run at about 60Mbps.)

not that you "can't get away with it" and install it stand-alone

I haven't posted the steps yet because I'm not 100% sure they will work. I have profiled WMP setup and I know all of the file locations and reg settings needed, but I'm afraid driver signing will stop it from working. (Normally you can just use a driver unsigned, but I think that class drivers might be special.)