Rockbox Technical Forums
Support and General Use => Hardware => Topic started by: bifter on April 01, 2010, 01:41:08 PM
-
Hi,
I've had a look through the forums so forgive me if I've missed any threads on this topic however I haven't found an answer.
I have a new car with a head unit that supports a USB connection to any device that can be presented as 'mass storage'. It works fine with the micro SDHC card in my HTC Hero, USB sticks and so on, however when I connect my iPod (4th gen greyscale) I get something like 'Device Error - Not Supported'.
'OK' I thought, 'I'll load Rockbox on my iPod and that will work!' However it doesn't. Whenever I connect the iPod I see a picture of a USB on the iPod screen and it displays 'Multimedia mode' and then reboots. I then get the error on the head unit and the iPod displays 'OK to disconnect'. I've tried fiddling with the HID settings in the menu but that hasn't helped. I also saw a suggestion to hold down the Menu button when the plugging the USB in but that doesn't work either.
Does anyone know if Rockbox can present the iPod as mass storage or, if not, any software that will? Cheers!
-
You're probably running a release build (3.5.1 if it's a recent install). Those have USB disabled because rockbox doesn't handle charging ipods from USB well at all. If you install a current build, it will use the rockbox USB implementation and not reboot, but you might have problems due to this charging issue.
-
Thanks for the prompt reply. I've tried installing the current build (r25423-100401) and you're right, it doesn't reboot. However the error message is still returned from the head unit. Any other ideas?
-
You could try disabling HID, but if that helps, I'd expect the Apple diskmode to also work.
One possibility I can think of is that the head unit matches the Apple USB ids. If that's the case, you could try with a custom rockbox build with different ids. You'd have to edit firmware/export/config/ipod4g.h in the rockbox source and change USB_VENDOR_ID and USB_PRODUCT_ID
-
http://cleansoap.org/files/Rockbox-r25432_NonAppleVendor-ProductID.zip
I had the same thought (that the stupid head unit is balking at known iPods), so I'd be very interested in this trial.
Question, though, is your music still in the Apple firmware created directory structure or are you using a "more sane" directory structure?
IF this build doesn't do the trick AND if you are using the Apple created directory structure the next test would be to delete the Apple directories and test if that is what the head unit is looking for.
-
Looks like, if I want to exhaust the options, I'll have to invest a bit of time and effort! While I would count myself as IT literate I'm not a developer, I was just looking for a quick fix to the fact that my iPod won't play through the USB connection on the head unit.
If I want to amend the source, does this mean I need to install SVN?
Incidentally we're talking about the VAG head unit (VW/Skoda/Seat) and yes, I am using the Apple created directory structure - I am aware that, even if I can get it working, this will simply present a bunch of randomly named folders and files to the head unit but at least I would be able to play the files on shuffle and use the steering-wheel mounted controls to skip tracks. If I got it working I would probably reload my music collection anyway.
-
I wasn't explicit before - but that link is to a custom build with the changes gevaerts was talking about.
-
Gotcha, cheers for that!
I was about to head off to bed anyway so will give this a try tomorrow. Am I able to just copy that folder structure over the top of the existing one or is there more to it? Sorry for noobness.
-
Overwrite existing directory structure with new.
-
Well, the head unit must be checking the ID tags because that firmware you provided works like a charm!!! Many, many thanks! :D
There will be a lot of happy people on the VAG forums when I tell them about this, except the ones that have forked out c.£60 for the manufacturer's cable - that uses the USB and the line in jack for some reason, plus cables all over the place!
Is this fix perhaps something that could be offered as an option in the settings for a future build? It's likely to be a common issue, more so now that USB connections are fairly standard in cars.
As for the charging thing, I'll keep an eye on that. The only slight worry when I was out and about earlier today was that my phone disconnected from the bluetooth, which it's never done before. It happened just the once and instantly reconnected but it seems a bit of a coincidence, presumably the head unit got a bit confused?
-
Is this fix perhaps something that could be offered as an option in the settings for a future build? It's likely to be a common issue, more so now that USB connections are fairly standard in cars.
It sounds like a work around for a bug in your car's USB driver, so I don't think this would be considered for the main build.
-
Making USB ids user-configurable sounds like a really bad idea to me, so the only real solution would be to drop the ids used by the original firmware altogether, but that would involve buying a USB vendor id, and those are not cheap.
I'm afraid there is no real good solution for this unfortunately. We'll have to think about which downside is the most acceptable.
-
Incidentally we're talking about the VAG head unit (VW/Skoda/Seat)
Do you know the model number of that headunit? I'm wondering if this will work in my car...
-
Do you know the model number of that headunit?
Not off the top of my head but the car is a Seat Leon, 2010 build. I think the unit is common to a lot of the VW, Seat, Skoda range just with varying display modules on them. My thoughts are that this solution should work for most, if not all VAG head units that have USB - see below.
It sounds like a work around for a bug in your car's USB driver
Having thought about this I'm not so sure. I'm pretty sure that Seat offer iPod integration as an option - an iPod connector either in the glove box or under the driver's seat - though now that I look I can't see that option on their Web site!
Anyway I reckon they may be using the ID tags to try and stop people just mounting their iPods as mass storage, thus forcing them to buy the integrated option or buy after-market cables.
Making USB ids user-configurable sounds like a really bad idea to me
Not sure that I follow? Isn't there a generic mass storage option that could be toggled in the settings, like you can use an agent switcher in a browser for example? Alternatively use Cowon or iRiver or something, for the reasons above it may be the case that the head units are only looking for iPod IDs. Sorry for my ignorance if I'm misunderstanding.
-
Making USB ids user-configurable sounds like a really bad idea to me, so the only real solution would be to drop the ids used by the original firmware altogether, but that would involve buying a USB vendor id, and those are not cheap.
I'm afraid there is no real good solution for this unfortunately. We'll have to think about which downside is the most acceptable.
Is there anything wrong with using a generic mass storage ID?
-
Is there anything wrong with using a generic mass storage ID?
There is no such thing.
-
The IDs belong to other companies. There's no such thing as a "generic mass storage ID." They identify the vendor and product of the device.
We contacted the USB-IF and were told that even though we implement our own USB code, we do not need to purchase our own USB IDs because we're using the original ones of the device.
If we were to start identifying as devices other than that which the player actually is (in terms of vendor ID and product ID) we would likely then need to purchase our own ID as the alternative one. This is expensive.
-
What about using the ID of an alternative manufacturer then? Is this illegal?
Is my example of browser agent switchers different? Firefox for example has an extension that fools Web sites into thinking that your browser is IE or Opera, etc.
If it were permissable I think this would be a useful feature. Not just for circumventing the VAG head unit parsing (if indeed this is what is happening) but I should imagine there might be other uses for it.
-
What about using the ID of an alternative manufacturer then? Is this illegal?
Is my example of browser agent switchers different? Firefox for example has an extension that fools Web sites into thinking that your browser is IE or Opera, etc.
If it were permissable I think this would be a useful feature. Not just for circumventing the VAG head unit parsing (if indeed this is what is happening) but I should imagine there might be other uses for it.
It's not illegal. If we would do this, the USB-IF might not be happy about it, but since we didn't sign any document they can't do much about it. From a technical point of view I really don't like it though. If a host refuses to believe that a device is Mass Storage because of its VID/PID, that host is broken.
Your browser user agent analogy does make some sense. These things can trick broken webservers into serving you content anyway, but they will also trick well-working webservers into giving you content that doesn't work because it was tweaked for the browser you now pretend to be (possibly to work around bugs in it).
Suppose you want to format and reinstall rockbox, so you plug it in, format the disk, and then run Rockbox Utility. How is that supposed to find out which player you have if you've changed the USB IDs?
-
If a host refuses to believe that a device is Mass Storage because of its VID/PID, that host is broken.
In this case it seems the manufacturer may have broken it deliberately. It would be pretty typical of Apple's approach to things and I guess VAG get some kind of kickback from the sale of iPod connectors?
Suppose you want to format and reinstall rockbox
Are you saying the tags are coded into the firmware? I guess I don't understand the technicalities but, if this is the case, does the utility not look at the Apple firmware to ascertain the model anyway? I'm guessing that these ID tags are still there as when I boot into Apple OS the head unit still rejects it.
In any case would there not be another tag that could be set and picked up by the Rockbox utility such that it would recognise that the IDs have been changed and prompt the user to manually select the player? Just a thought.
-
It still seems a bad idea to antagonize the USB-IF (there's no guarantee we'll never need something from them in the future) to accommodate broken behavior in other software.
Have you tried contacting the manufacturer and asking if it's intended behavior that their device won't play MP3 files on an MSC device if it accidentally identifies it as an iPod?
-
Are you saying the tags are coded into the firmware? I guess I don't understand the technicalities but, if this is the case, does the utility not look at the Apple firmware to ascertain the model anyway? I'm guessing that these ID tags are still there as when I boot into Apple OS the head unit still rejects it.
How does it know it's an ipod? You've just changed the IDs to say it's not.
You can't just assume that you can reboot to the OF to get to a working disk mode. Ipods might have that, but rockbox supports a lot more.
I don't want to give the impression that we don't want to support this head unit, we do... It's just that we don't want to jump to an option we really don't like without seriously thinking about it and considering the alternatives.
I suppose you can't borrow me your car for a few weeks to investigate? ;)
-
LOL it's just a flat 1.6, not a Cupra or anything fancy!
Totally understand where you're coming from. I think you're being quite patient with me really, explaining the technical issues and such.
Right now I've got something that works, which is great. I'm not sure what Soap did to make it work but it would be good to be able to replicate it if I want to upgrade Rockbox - e.g. if the USB charging issue gets sorted out. Also I know that there would be other people - e.g. on the Seat forums - who would be interested in this. That probably goes for a lot of VW and Skoda owners too and maybe other makes.
-
Thank you very much for testing this. I've suspected such idiotic anti-consumer behavior on the part of certain manufactures before, and it is nice when there is proof.
I think the USB vendor and product IDs should be settable in the "debug" menu - it would make *cough* debugging USB behavior all the easier, and Rockbox can sleep soundly at night knowing that only developers would ever change those settings.
EDIT:
What did I do? I changed the vendor ID to 0x029a and the product ID to 0x002a. (gevaerts has already mentioned where the changes need made) - you would need to compile your own Rockbox build from the source code (something Rockbox makes quite easy - check out the wiki).
-
I'm *reasonably* sure that your suspicion of anti-consumer behaviour is wrong. It's detecting that it's an iPod, and trying to use the advanced accessory protocol (the one that works over USB/SCSI) to retrieve information about the files on the device. A normal un-rockboxed ipod would be unusable if it *didn't* do this, because the files have been renamed to useless unbrowsable names by iTunes and you wouldn't be able to find anything. We don't implement this protocol because we don't have any docs for it, so the connection fails. I guess the head unit *could* fall back to just letting you browse the filesystem, but since this would never have come up during testing it's a reasonable mistake to have made without any malice being required.
The 'right' fix in the long term is for someone to painstakingly reverse engineer the protocol used and implement it in Rockbox.
-
I'm *reasonably* sure that your suspicion of anti-consumer behaviour is wrong. It's detecting that it's an iPod, and trying to use the advanced accessory protocol (the one that works over USB/SCSI) to retrieve information about the files on the device. A normal un-rockboxed ipod would be unusable if it *didn't* do this, because the files have been renamed to useless unbrowsable names by iTunes and you wouldn't be able to find anything. We don't implement this protocol because we don't have any docs for it, so the connection fails. I guess the head unit *could* fall back to just letting you browse the filesystem, but since this would never have come up during testing it's a reasonable mistake to have made without any malice being required.
The 'right' fix in the long term is for someone to painstakingly reverse engineer the protocol used and implement it in Rockbox.
Couldn't it read the database just like the iPod itself does?
Personally, I think Apple should not have "reinvented the wheel". A filesystem is a very good way to organize data. The files could be stored as "artist/album/track" on the disk and playlists implemented as a list of files.
-
.
Couldn't it read the database just like the iPod itself does?
No, because Apple change the database format whenever they feel like it. The protocol allows them to do this. The database format is not public or stable; the protocol is available to anyone who pays apple.
Personally, I think Apple should not have "reinvented the wheel". A filesystem is a very good way to organize data. The files could be stored as "artist/album/track" on the disk and playlists implemented as a list of files.
Well they didn't do it that way, so this is useless wishing :)
-
http://www.obdev.at/products/vusb/index.html
Comes with freely usable USB identifiers (Vendor-ID and Product-ID pairs).
...
You can choose the License: Open Source or commercial.
Maybe those IDs or some other free IDs can be used?
I'm *reasonably* sure that your suspicion of anti-consumer behaviour is wrong. It's detecting that it's an iPod, and trying to use the advanced accessory protocol (the one that works over USB/SCSI) to retrieve information about the files on the device. A normal un-rockboxed ipod would be unusable if it *didn't* do this, because the files have been renamed to useless unbrowsable names by iTunes and you wouldn't be able to find anything. We don't implement this protocol because we don't have any docs for it, so the connection fails. I guess the head unit *could* fall back to just letting you browse the filesystem, but since this would never have come up during testing it's a reasonable mistake to have made without any malice being required.
But don't the release versions use disk mode, which is hard coded in the stock firmware and not Rockbox code?
-
How would us using their ID pairs be any different than us stealing them from another unrelated project? Just because they're open source and we can use their code freely doesn't mean we still wouldn't be misusing the vID/pID pair they use if we included it in our code, nor does it address any of gevaerts' other concerns about using pairs that aren't right for the device.
As well, I don't understand your statement about the OF disk mode. What it does is entirely unrelated to this discussion, since this discussion is about what what Rockbox could or should implement to solve the problem. Rockbox release versions won't always depend on the OF USB mode as that's just a temporary situation, and he's already moved beyond using the OF USB mode in his own personal use.
-
How would us using their ID pairs be any different than us stealing them from another unrelated project? Just because they're open source and we can use their code freely doesn't mean we still wouldn't be misusing the vID/pID pair they use if we included it in our code, nor does it address any of gevaerts' other concerns about using pairs that aren't right for the device.
If I understand things correctly, they have a deal with some people who own a VID to get a range of PIDs, which they allocate to users of the project on-demand, so from a technical point of view this is fine.
I'm pretty sure that the actual owner of the VID is in breach of the contract they signed with the USB-IF however. The vusb people claim that they aren't doing anything wrong, not having signed anything with the USB-IF, and I think they're right.
My personal opinion is that while getting a deal like that might be fully legal, I still don't like it...
-
As well, I don't understand your statement about the OF disk mode. What it does is entirely unrelated to this discussion, since this discussion is about what what Rockbox could or should implement to solve the problem. Rockbox release versions won't always depend on the OF USB mode as that's just a temporary situation, and he's already moved beyond using the OF USB mode in his own personal use.
If the iPod is running a version of Rockbox that uses the stock firmware disk mode and the car radio won't work with it, then Rockbox is very unlikely to be the problem since the iPod is not running any Rockbox code while it is connected to the radio. (It could, however, insert a delay or glitch that causes the problem.) The fact that it will work only if the USB IDs are changed strongly suggests it is indeed a trick by the manufacturer to buy their overpriced cable. (Note that the stock firmware disk mode did not work, nor did Rockbox disk mode with the stock IDs. But Rockbox disk mode with custom IDs did work.)
If it's legal to do so (are USB IDs copyrighted?), I think it should be possible to change the USB IDs, but leave them set to default. I consider that a workaround for "broken" hardware and I remember that even the Linux kernel has a lot of such workarounds. It's really no different from spoofing the user agent of a browser to work around "broken" websites. Maybe implement it as a variable in the cfg file but no menu entry so it cannot be changed by accident. The few users with a need to change the ID can open the cfg in a text editor and add it in manually.
-
I think the best solution is to do the right thing and present the correct USB ID. If anyone needs to work around something, they can change the ID themselves. Introducing weird things like configurable IDs makes no sense when they're only useful for a handful of people.
-
I think the best solution is to do the right thing and present the correct USB ID. If anyone needs to work around something, they can change the ID themselves. Introducing weird things like configurable IDs makes no sense when they're only useful for a handful of people.
Agreed.
-
If the iPod is running a version of Rockbox that uses the stock firmware disk mode and the car radio won't work with it, then Rockbox is very unlikely to be the problem since the iPod is not running any Rockbox code while it is connected to the radio.
This isn't entirely true; we reboot into the emergency disk mode in ROM which is unlikely to implement whatever protocol is required. This is *not* the same code as the OF uses if you just connect the USB cable after booting the OF. But yes, if that doesn't work either then the manufacturer is just being a pain :)
-
For example, there's really no reason at all for emergency disk mode to support the accessory protocol, so if the host device is expecting that, disk mode probably won't cut it.
-
I think the best solution is to do the right thing and present the correct USB ID. If anyone needs to work around something, they can change the ID themselves. Introducing weird things like configurable IDs makes no sense when they're only useful for a handful of people.
I think they should be available to users without having to have them know how to compile firmware. Putting in a menu option will just add clutter but making it settable in the cfg file is fine.
-
We generally try to avoid settings that are only changeable in the config file.
Either something is a setting that is in the menus, or it's something that shouldn't be changed directly (for example, some theme settings), or it's not a setting at all. There really isn't a middle ground for "hidden settings." In a few cases there may have been exceptions, but it's not a desired solution.
You have to understand that generally there's a preference for "take our time and do it right" rather than "put in a hack that'll get the job done until we can come back to it later."
-
Just an update on this topic from my perspective.
For about £20 I was able to get a second hand 80GB 2.5" HDD and an enclosure and this runs nicely on the USB port in the car, sits there permanently now - simple solution.
I still think it would be a nice feature for some people to be able to mount their iPod but appreciate it's a bit of a niche request and raises a few implementation issues.
-
Hello all,
Hope its ok to comment on this topic with a question myself.
I have been a verry happy user of the rockbox firmware for a long time and only now discovered this helpfull forum.
I have the same "problem" with my new car radio as bifter, only difference is i have the iPod color/Photo instead of the greyscale 4th gen.
I first tried using the custom firmware that soap linked to on mine but then the ipod would not boot anymore. I alos tried compiling myself but that seems a little to complicated.
Now my question is, if soap or someone else with the knowledge to compile can give me a compiled formware with the changed vendor id's (the same as soap did on page 1). but then for the ipod color/photo?
I would be really thankfull if someone could help me with this so i could still use my beloved rockbox/pod in the car!
Thanks in advance! (excuse the bad english, dutchman here...)
-
Just bought a 2010 Nissan Altima. It has a Bose stereo w/USB port and it will only recognize my Rockbox'd iPod 80GB 5.5 when booted to the Apple OS (where I have no music loaded). I'll try the unsupported build linked in this thread but will probably wind up using the old 20GB HD from my dead AJBR20 in a USB case.
I have to believe that as USB ports become more common in new cars, this problem will continue to grow. This situation does make RB less useful, to me at least. Please consider making the USB ID user-configurable in a future release.
-
It isn't very much work to learn how to compile. This is the best solution since you will be able to make your own builds with this change (the custom ID) any time you want (like when a new change that you want is included in current builds).
-
Please consider making the USB ID user-configurable in a future release.
We have considered it, but nobody has proposed something generally acceptable yet. Just allowing the user to enter any value is pretty disastrous from a usability point of view, tbh; there are all kinds of problems that might result from users picking values that collide with other existing devices, and we don't want to recommend a particular alternative value either as this is in conflict with the letter and spirit of the USB-IF standards.
-
It isn't very much work to learn how to compile. This is the best solution since you will be able to make your own builds with this change (the custom ID) any time you want (like when a new change that you want is included in current builds).
I have been wanting to do that for a while but it's just one more think on the ol' TODO list...
UPDATE:
Setting up a compile environment is NOT easy for non-linux developers. I've wasted a morning and still can't get Ubuntu 9.04 to install SVN. All to just get my RB's iPod to work in a new car.
Is there a Ubuntu RB development appliance available anywhere?
-
Stringrazor, if you have trouble with that it would probably be better to start a new topic in the "compiling" forum. People will be happy to answer your questions and assist you there.
These instructions should work if you're using Ubuntu:
http://www.rockbox.org/wiki/LinuxSimpleGuideToCompiling
-
Thanks, as I posted over there, my frustrations were caused by a netnanny filter at work. Everything worked fine from home and I've compiled my 1st build. Now, to hack the USB ID...oh, I guess I'm not suppose to say that out loud.... ;)
-
No, you are perfectly entitled to say that. We have no problem with users making any modification they want; only your own device will be affected and it's your own business.
We are concerned about standards with respect to the code the project distributes, not what people do with it :)
-
I was kidding of course...
Once I got past my site blocking problem, creating a build environment and changing the USB ID was easy thanks to the info in this thread. I'll test it in the car later but my PC thinks I simply have have a Toshiba HD attached when I connect the iPod via USB while booted to my own compiled RB version.
Thanks for your help. I'm dangerous now and may even start messing with the code someday... :P
-
You are also now in a position to be able to test and provide feedback about patches in the patch tracker. :)
-
And that may be the most good that comes out of this little exersize.
The head unit (Bose from Nissan but I've read it's actually made by Panasonic) now recognizes the RB-booted iPod as a generic USB device but balks fatally after it finds more than one or two "unplayable" files. From the little information of any depth I've found about the USB function of the unit, it looks like it uses the order the files & folders were written to the OS as the playback order. How disappointing! I have a cheap USB stick/MP3 player that works like that and found a utility that will reorder files for a specific playback order and I'll give that a try but I think the head unit is just too dumb to work with the files I have on the unit that RB knows how to handle.
Maybe I can at least config one folder it can get to and handle. Oh well, I won't be driving that car that much anyway. I'll also have to put songs in the OF structure with iToons and see how the unit handles iPod-specific control.
Anyway, sorry for the mostly OT post. At least I was able to successfully modify, compile, and deploy the code to get the device to not look like an iPod.
-
http://cleansoap.org/files/Rockbox-r25432_NonAppleVendor-ProductID.zip
How are these files used? Simply copy them to the iPod, or are they part of a custom installation?
Thanks!
-
It's a firmware archive, so it can be installed manually like others (i.e. extract it to the root of your player).
-
Really, the point of that build was to test if the head unit was being a dick and balking at the Apple USB ID.
That test has been concluded, and yes, dickishness was involved.
I'm want to pull that build off my server when I get home, as I don't want to encourage people to use a seven month old build when the Rockbox community has done such a fine job in creating the tools to build rockbox oneself.