Thursday, October 11. 2007Go Solid Go!I've been rather silent on the topic of progress in media devices. Part of this is that much of the work has happened behind the scenes. Just yesterday I spent hours editing device definitions in libmtp and libnjb so that they'd be able to propagate the correct vendor and product info through hal, because hal's handling of it leaves something to be desired. For instance, on my Creative Zen MicroPhoto, it correctly detected the vendor and product. Except that the part of the device detected as a portable media player was the USB interface for the device, for which the vendor was blank and the product name was "USB Interface." Another reason for the long delay was a partially failed experiment that aimed to provide support for many different media devices via a centralized kioslave. It's not that this couldn't still happen, at some point, but it becomes extremely difficult to map protocols that have no notion of filesystems into a filesystem, and have filesystem clients behave properly. There was another foray into a different system that also ended badly -- mainly because there was no way I'd get it finished within a year, much less within a few months. In the end it was decided that Amarok's device plugin system is really pretty decent, providing relatively bug-free and easy device management for almost every device on the market...and if it ain't broke, don't fix it. Of course, it's using tons of deprecated classes and methods, but as Trolltech says (my emphasis), "we recommend against using these classes in new code." Good point. So let's get stuff working, and then we can try to design a new, better system in parallel -- but at least something will work in the meantime. So with that decision made, I worked on integrating with Solid. I'm happy to report that today, I plugged in my Creative Zen MicroPhoto, and it was instantly detected and the correct plugin selected. All I had to do was hit Connect. Screenshots:
The first screenshot shows what the media browser looks like with nothing plugged in. At that point, I plugged in my Creative Zen MicroPhoto, and you can see that it was detected and added to the device selector drop-down box:
After this, I hit the Connect button (it's the one on the top left) and artists were displayed. I hit the custom button just so you could see some of the details available:
So it's coming along. I expect this device detection to work on pretty much any kind of music player (except generic/vfat/UMS...more on that on a later post, when I have time to work on it), provided that:
So that's it for now. The next step is to get manual adding of devices working again. And after that, dealing with generic devices in a smart way (the way will be Banshee-compatible too...thanks to Aaron Bockover for the excellent idea!) In the meantime, watch out for the Amarok Device Donation Program. Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Something unrelated I just want to say.. these screenshots look freaking sweet!
I was a bit worried with the first previews, but this is just awesome! Keep up the good work guys!
wow, great work. i'm really looking forward to the new amarokka.
I'm really looking forward to the new implementation of media devices.
I just wanted to know if the loading of the soundfiles on the devices runs now in it's own thread. Because in Amarok 1.4.6 I have to wait about 5 minutes before the program takes any new GUI inputs (80gig IPod). This is really annoying. How far are you with the integration of the mediadevice in the sound library? So that the soundfiles on the device are handled like the were in the database. This would be awesome!
Well, don't get your hopes up too much yet. This isn't a new implementation of media devices -- that's what I wanted to do, and what I simply don't have the time to do. It's more an update to what already exists, with the main feature being autodetection of devices and autoselection of the correct libraries.
As for loading soundfiles in a new thread, I've not looked at the ipod plugin since, well, I don't have an ipod. Martin may look at that, or I might if someone donates me an ipod. It is theoretically possible but we'd have to be very, very careful to keep things thread-safe, and I'm not sure how easy that would be. As far as integration of the mediadevice into the collection, that remains to be seen. It's on my "I'd like to see it happen but it's not a priority" list. First priority is get stuff working at least as well as before. I'm hoping that for release we can at least have sound files displayed in the collection browser, even if you can't write files to the device that way. Incidentally, integrating everything into the collection manager was one of the things I was working on that I've given up on. It's possible, and for the design of a future parallel media device handling system that's probably the way to go. But it's too much code changing and too time-intensive for me to deal with right now. So at least something will work for 2.0, even if it's not the ideal.
Sound files from media devices displayed in the collection browser is the one feature I really would like to see. The file handling is not so important for me.
I just want to play my music on the IPod with all the great Amarok features. This would make it possible to take my IPod with me and plug it into another computer and use Amarok without copying all files on the hard drive first (80gig is a lot for a laptop). I had a look into the old IPod plugin source. When the IPodDevice is opening (connecting), all the files, playlist, podcast have to be inserted in the media device playlist view. This takes for my IPod a long time. You can not unconnect your media device or even stop the current running song. The GUI just hangs in the "load in view" loop. I don't think this is only an IPod issue. Maybe if the mediadevice integration in the collection browser is happening you think of a way to update the information from the mediadevices without freezing the whole program. Or at least a status bar would be nice
We all want sound files from media devices displayed in the collection browser too
As for the ipod-loading-making-gui-freeze thing, it'll get addressed at some point, but it's less critical than making sure that people can access their ipods in the first place
I just wanted you to know about the problem. I understand that this isn't a critical feature
Thanks for the fast replies and good luck for the 2.0 release!
As far as i know (as 1g nano user) ipod model can be recognized by usbid. Implementation could be kludgy, but sexless syncing with almost any DAP is definitely way to go!
Thanks for work on amarok!
From what I remember discussing with the libgpod guys, there are some issues with that -- I think it was that many of the usb ids are reused. The biggest issue was actually the fact that many of them didn't see a need for an fdi file to be provided, since they get lovin' from the default hal rules. They do have a point, but there are some drawbacks.
But regardless, it's not really a problem. All that's important for Amarok is that hal detects that the protocol used by the device is ipod...and since the default rules are "storage.vendor contains Apple" and "storage.model contains iPod" this matches everything on the market (excluding the iPhone). (One drawback here to libgpod not providing a fdi file is the fact that if a new model came on the market with a new access protocol, they could get their fdi file updated far faster than a new release of hal is likely to come out...but that's to deal with later, I suppose). Once the device is connected, the proper name can be grabbed from libgpod based on the database and whatever other things it uses.
Jeff,
Check what the guys from Rockbox (www.rockbox.org) are doing: they have autodetection for all types of iPod going, in both windows and linux (its part of their installation utility). It took some figuring out, but it works. Starting point: http://www.rockbox.org/twiki/bin/view/Main/RockboxUtilityQt
Lots of programs can autodetect what types of iPods they're talking to. But to do so, they have to talk to the iPod. It's an active thing, unlike the passive way that hal gathers information. So once we connect to the iPod with libgpod there's no trouble figuring out what type of iPod it is. It's figuring out what type it is from hal (and again, it may be quite possible, but the libgpod guys were only half-interested, by which I mean only half of them were and no one seemed to care that much).
There was one approach by Aaron Bockover where he made a program that acts as a hal callback, accesses the device, and figures out more information. But unless that's included as a part of hal or a part of libgpod (and is installed...after all, packagers usually don't install fdi files, so callbacks will be even harder to get them to package) it's technically great but practically useless, because we can't assume it'll be there. So in the end we'll probably have to just do the simple detection and then once it's connected via libgpod a better understanding of the device can be acquired. |
Amarok LinksCalendar
QuicksearchCategoriesSyndicate This BlogBlog Administration |
|||||||||||||||||||||||||||||||||||||||||||||||||

