stecchino

Amarok Blog

Friday, March 13. 2009

Amarok podcasting 2.0 and post-2.0 plans Posted by Bart Cerneels in stecchino at 00:52

Comments (0)
Trackbacks (0)

Amarok podcasting 2.0 and post-2.0 plans

Hey fellow developers and users,

In Juli 2007, at Akademy Glasgow I started implementing podcasting support in Amarok2. Since then I was sidetracked a little, as you may be aware.

The little time I did manage to spend designing and implementing was short and far from focused. So a lot of features are not finished or just plainly missing. The framework I created underneath suffered from the same lack of focus and is need of a good review. I'm aware there is probably some overdesign and some parts might be to complex. If you feel you can help in that area I suggest you take a look at extragear/multimedia/amarok/src/podcasts . Send questions, comments and suggestions to amarok-devel@kde.org .

The 3rd beta from Amarok 2.0 is already out the door and podcasting support is still not finished. In order to make it I had to reduce some goals I had set for myself during those rainy summer days in Scotland. Here's the plan:

Amarok 2.0:
The focus ATM is on finishing the SqlPodcastProvider, Podcastmodel and PodcastCategory (GUI).
SqlPodcastProvider uses tables in the standard SQL database, adds and updates the feeds using PodcastReader and downloads to disk using the regular KIO-jobs.
To make the podcasting fully functional though we'll need to reintroduce:

Autoscan the feed for updates
Download when available
Episode purging (delete downloaded episodes automatically)

The settings dialog for this exists, next up is using them

.
The GUI currently shows all episodes ever read from the feed, which obviously needs to be addressed.
The GUI for 2.0 should be very similar, if not identical to Amarok 1.4, probably minus folder tree grouping support since that is better handled generically for all Playlists (which PodcastChannel is in our class diagram).

If anyone has a bit of Qt Model/View experience and would like to see podcasting in Amarok 2.0 I suggest you send a mail to amarok-devel@kde.org or ping me on irc (Stecchino on #amarok).
Without help we might have to drop it's from 2.0 completely because it's a bit much for me alone to complete and stabilize.

Amarok > 2.0:
I do have a plan for a complete GUI overhaul post-2.0. I'll get some art and usability advice in another blog post when the time comes.

The 2.x releases should see more advanced features being introduced that the framework is already designed to support:
For the SqlPodcastProvider specifically:

Renaming and sorting individual episodes (popular request)
Purging based on episode age and/or total size on disk
Labeling of PodcastChannels (perhaps to replace traditional folder tree grouping)

More general

Mediadevice Podcast support: iPod being the most advanced implementation but also generic usb devices, music phones and Canola2, I'm sure the INdT guys could help us with that.
OPML import and export
Podcast Directory personal subscription list.
BashpodderProvider: to use bashpodder and Amarok in parallel with synchronized download status
...

On to hacking.

Friday, February 13. 2009

UPnP support in KDE and Amarok Posted by Bart Cerneels in stecchino at 20:12

Comments (0)
Trackbacks (0)

UPnP support in KDE and Amarok

During FOSDEM [ade] and I met with Frank Scholz, the lead developer of Coherence. We discussed DLNA/UPnP and how Coherence can be used in KDE and Amarok. The conclusion of this meeting was that we should use Coherence as our base for supporting UPnP services in KDE. The first implementation will be a KIO slave for browsing media stored on remote devices.

UPnP is a network technology using a combination of SSDP, XML and SOAP, with some GENA thrown in for eventing. A group of UPnP services called the UPnP A/V Architecture has been picked up by an industry organization called the Digital Living Network Alliance. DLNA specifies device classes which have to implement specific services and support a minimal set of filetypes and codecs.

Coherence is a framework, written in Python but it exposes a DBUS API, that allows an application to participate in the "Digital Home Network". For the moment this means mainly UPnP, but support for Ampache is available and Apple's DAAP is also considered. It's published under the MIT license and is multiplatform.

In Amarok we have been planning to integrate UPnP for a long while. But except for a failed Google Summer of Code project last year not a lot of effort has been spend. Thanks to Coherence this will quickly change: in relative short term (read 2.2) we will introduce a UPnP Collection that will list and enable playback of music stored on a DLNA Digital Media Server.

We could even consider publishing the content in the local Collection, basically making Amarok a DMS. Amarok can then track plays on remote devices and use it in the scoring algorithm.
Even more advanced functionality would be to control one or more Digital Media Renderes, such as
the Philips Streamium, from Amarok.

A few mails have been going back and forth between interested developers about discovery of network services in general. In order to simplify using technologies as UPnP, zeroconf, Samba, etc I'm wondering if we can integrate this in Solid. Only the discovery part obviously, using the services would be the task of separate frameworks, such as Coherence. With this functionality in Solid it should be trivial to show a kind of "Network Map" to the user with all the services per device.

As you can tell, plenty of cool things to keep a few people busy for a year or 3.

Bart

Monday, February 2. 2009

Amarok Junior Job: Auto-download new ... Posted by Bart Cerneels in stecchino at 19:12

Comment (1)
Trackbacks (0)

Amarok Junior Job: Auto-download new podcasts

A recent comment by progmanos on the post of the 2.0.1.1 release reminded that I still have to implement Podcast episode auto-downloading. In the hurry to get 2.0 released I did add the config option, but forgot to add the actual code to make it work.

In Amarok 2 Podcasts are implemented in classes derived from PodcastProvider. There can be mutliple providers, which allows for instance podcast syncing between Amarok and an iPod.
The default provider is SqlPodcastProvider. This is where the auto-download function should get implemented.

This is a nicelly contained and not to steep introduction to Amarok development. So it's an excelent Junior Job.
If progmanos or anyone else would like to have a go at it, contact me on #amarok on irc.freenode.net. My nickname is Stecchino.

Wednesday, November 12. 2008

Amarok podcasting 2.0 and post-2.0 plans Posted by Bart Cerneels in stecchino at 11:22

Comments (2)
Trackbacks (0)

Amarok podcasting 2.0 and post-2.0 plans

Autoscan the feed for updates
Download when available
Episode purging (delete downloaded episodes automatically)

The settings dialog for this exists, next up is using them

Renaming and sorting individual episodes (popular request)
Purging based on episode age and/or total size on disk
Labeling of PodcastChannels (perhaps to replace traditional folder tree grouping)

More general

Mediadevice Podcast support: iPod being the most advanced implementation but also generic usb devices, music phones and Canola2, I'm sure the INdT guys could help us with that.
OPML import and export
Podcast Directory personal subscription list.
BashpodderProvider: to use bashpodder and Amarok in parallel with synchronized download status
...

On to hacking.

Tuesday, March 13. 2007

Podcast appliance Posted by Bart Cerneels in stecchino at 18:57

Comments (0)
Trackbacks (0)

Podcast appliance

Imagine a device dock, device in this case being a phone, iPod or any other media playing device, that is connected to the Internet and will download podcast episodes and put them on the device.

This piece of python code is supposed to run on an embedded device without storage. Just a small box that is connected to a docking station using USB. When a USB plug event is detected the main code queries the device specific Plugs for device presence. Podcasts are downloaded and stored directly on the device, without using any intermediate storage. When an episode is saved successfully it's status is saved in a database on the device. Listened episodes can be marked as such in the database. All configuration, database and storage is device dependant and implemented in a device plugin.

I can envision more capabilities like BitTorrent support and integration with web-services and maybe an Amarok script to sync the database.

The code is very rudimentary, only 2 plugs are implemented:

local storage plug: for testing purposes, can be reused for devices that can be mounted with usb-storage.
ObexFTP plug: I plan to use this for uploading podcasts to my cellphone. It still uses temporary storage until I add the necessary code to ObexFTP and OpenOBEX.

I haven't put copyright information in the files yet. Mainly because it is using a lot of other code and I haven't bothered looking at the licences. Feel free to use this code anyway you like.

I plan to use this code to upload podcasts to my phone from many different computers and embedded platforms without running any commands manualy. That means PodcastGrabber has to run as a service, listening to USB events, I might use HAL for that, but I doubt HAL is very useful on low-storage embedded platforms.

Tuesday, March 13. 2007

KDE4: actions menu Posted by Bart Cerneels in stecchino at 17:57

Comments (2)
Trackbacks (0)

KDE4: actions menu

Task driven menu for applications.
Have a "actions" menu in every kde application containing the most common actions you can do with it. ex. Amarok: "Play Media", "Play Audiocd", "Quit". When using the desktop menubar the actions menu gets renamed to the application name. See my previous post to see why that is useful.
Every user is different so it could change the order of the actions menu depending on the users usage of those actions. It can even insert actions that are not there by default. I guess most items in a well designed menu can end up in the actions menu. The developers have to tag menu items as actions but only a few of them (most used or default) end up in the actions menu. And, since automation seems to be bad usablility wise (according to Ellen), users and developers are able to pin items to the menu.
If you are shouting "this is similar to XP's start menu or the Kickoff menu". You are right, only on a single application level and much finer grained.

In Amarok we had the problem that users weren't finding the features we worked so hard to invent and implement just about every release. This actions menu could help the discoverability of otherwise hard to find but wonderful features without bothering them with things like "tip of the day" or that damn paperclip.

Comments are welcome

Tuesday, March 13. 2007

Podcast appliance Posted by Bart Cerneels in stecchino at 17:45

Comments (0)
Trackbacks (0)

Podcast appliance

Imagine a device dock, device in this case being a phone, iPod or any other media playing device, that is connected to the Internet and will download podcast episodes and put them on the device.

This piece of python code is supposed to run on an embedded device without storage. Just a small box that is connected to a docking station using USB. When a USB plug event is detected the main code queries the device specific Plugs for device presence. Podcasts are downloaded and stored directly on the device, without using any intermediate storage. When an episode is saved successfully it's status is saved in a database on the device. Listened episodes can be marked as such in the database. All configuration, database and storage is device dependant and implemented in a device plug.

I can envision more capabilities like BitTorrent support and integration with web-services and maybe an Amarok script to sync the database.

The code is very rudimentary, only 2 plugs are implemented:

local storage plug: for testing purposes, can be reused for devices that can be mounted with usb-storage.
ObexFTP plug: I plan to use this for uploading podcasts to my cellphone. It still uses temporary storage until I add the necessary code to ObexFTP and OpenOBEX.

Wednesday, February 28. 2007

KDE4: Backstage Posted by Bart Cerneels in stecchino at 18:33

Comments (5)
Trackbacks (0)

KDE4: Backstage

The system tray is a limitedand valued realestate. Besides that it is extremely limited, smal icons make it hard to aim and actions can only be added in a menu, usualy right click menu, which is a problem all by itself.
But the problem is there are a lot of apps that use it as a mini taskbar. Like amarok, kontact, kopete, ... to many to name. And then there's superkaramba with widgets to control programs like amarok and other widgets to display feeds.
There's an opportunity here, what to do if programs want to remain running without a window open? Minimize them to the desktop as a widget. Of course this is not new, it's a concept used in CDE and probably others, they just create a icon on the desktop. But this is something different, so bear with me.

I call this concept Backstage, it would be a part of plasma and a there would be a framework to create Backstage widgets as easy as creating a system tray icon.

As example: the backstage widget for amarok

When sitting idle on the desktop and amarok is not playing the widget would look like the big amarok icon without the buttons.
If you move the mouse over the widget the actions swirl around the icon and stop where they are in the image.
When a track is playing the artist and title would rotate around it and the progress is visible by the percentage of the icon that is in grayscale.
Clicking on the action buttons does the expected thing, clicking somewhere else on the widget restores the amarok main window.

Practically I would implement this with animated SVG's for the graphics, Python for the behavior and DCOP for the communication with the parent application.

Off course the system tray doesn't need to dissapear completely but at least KDE4 apps that run in the background should have a backstage widget and let the user decide.

Wednesday, February 28. 2007

KDE4: Improved desktop menubar Posted by Bart Cerneels in stecchino at 18:33

Comment (1)
Trackbacks (0)

KDE4: Improved desktop menubar

I use the desktop menubar all the time. Mainly because it saves some vertical pixels on every window, very useful on my widescreen laptop. I looks cleaner to.
For those of you that don't know what it is. The desktop menubar shows the menu of the focused application (instead of in the top of the applications main window). It's a feature borrowed from MacOS.
unfortunately unlike in apple's OS the menubar doesn't contain the name of the application the menu belongs to. That creates some confusion for those not used to it and sometimes irritates me.

I suggest that in KDE4, instead of the usual "File" menu (or in amarok 1.4-svn "Engage") be changed to the applications name when using a desktop menubar. Actually, isn't File a bad place to put the quit item? Settings would fit better in there to. KDElibs4 should just rename the first menu to the application-name or just add a icon in front of it like in the screenshot. I guess a lot more people will start using the menubar then.

Wednesday, February 28. 2007

first post Posted by Bart Cerneels in stecchino at 18:33

Comments (0)
Trackbacks (0)

first post

The best ideas are common property.
Seneca (5 BC - 65 AD), Epistles

I agree with the ancient roman guy, thats why I'll post the idea's I get on the most impractical times in the most awkward places on this blog.

I'm Bart Cerneels, a.k.a. Shanachie, a.k.a. stecchino, a electronics engineer, free and open-source enthusiast and KDE hacker.

Want to know what goes on in my head when my eye's turn glazed and I reach for my notebook? Read this blog!

Wednesday, February 28. 2007

Honor system for BitTorrent Posted by Bart Cerneels in stecchino at 18:33

Comments (0)
Trackbacks (0)

Honor system for BitTorrent

Say a vidcaster wants to earn some money with his content, or a great, but canceled, tv-series wants to make a comeback by publishing the episodes on the web. They could try advertising, but aren't the irritating ads the reason why we don't watch TV anymore? Maybe they can ask for a small fee to download the shows, right after they are produced. But would people pay if the show is for download on the P2P nets a few minutes later? Surely DRM is no solution, who in their right mind pays for a crippled file, that might not play on your favorite mediaplayer or portable device. For independent content producers, hosting large video files will be a problem to. Even if the show becomes popular, the income will not be enough to pay the bandwidth-bill.

The cost of distribution can be avoided when using BitTorrent with your own, private, tracker. And by using fingerprinting instead of DRM, customers can play the file on any player that supports the codec, without restrictions.

What I propose is to distribute the files over BitTorrent in a video format that uses keyframes, like xvid and other MPEG4 codecs.
When seeding a file BitTorrent chops it up in small blocks, some of these blocks will contain a complete keyframe. The blocks containing those keyframes are not distributed over BitTorrent but send to the subscriber individually. The BitTorent program will then add those blocks to the publicly distributed blocks and then assemble the complete file. The difference is that a fingerprint is added to the keyframes, identifying the subscriber. The fingerprint is visible but only until the next keyframe comes along, usually within 30 seconds. So transcoding will not remove the fingerprint and trying to mask it will obscure the video.

The content providers use a service that takes care of the BitTorrent trackers, the finger generation and payment.
Users of this service buy credits which they can use for every video that's distributed by the service.
After downloading the fingerprinted keyframes, a certain amount of credits is deducted from their account. If a user breaks the rules, leaks a file, and gets caught, he loses all of his remaining credits. If there aren't any credits left, the user gets excluded from the service for a while.

The big pluses:
Bandwidth cost are reduced with BitTorrent. No DRM is used, yet illegal distribution is discouraged by the honor system.
If similar fingerprinting techniques are possible for other kind of codecs, like mp3, they might be distributed in the same way.

Wednesday, February 28. 2007

Sony-Ericsson K610i + HBH-DS970, a ... Posted by Bart Cerneels in stecchino at 18:33

Comments (2)
Trackbacks (0)

Sony-Ericsson K610i + HBH-DS970, a Linux users experience

This isn't a full review of either the phone nor the stereo Bluetooth headset, for a detailed report with pictures and the works read: mobile-review.com k610i and bengalboy about the HBH-DS970 headset

The K610i is 3G candybar feature-phone (not smartphone) with Bluetooth 2.0 , 2 MegaPixel camera and a low-res. camera in the front for video calls.
The kind of phone I was looking for should have:

A2DP support for using a stereo Bluetooth headset.
camera >= 2.0 MegaPixel
media player application (guess that comes with the A2DP)
preferably a smartphone for replacing the mediaplayer if necessary.

The K610i was actually the cheapest phone on my list, unfortunately it's not a smartphone.
It came without headphones. I didn't bother buying a wired, and pretty expensive, Sony-Ericsson stereo headphone, but ordered the HBH-DS970 A2DP stereo Bluetooth headphones from Expansys.

A quick explanation about A2DP:
The Advance Audio Distribution Profile is a recent addition to the standardized Bluetooth profiles and is possible to implement on devices with Bluetooth 1.2 or higher. It allows CD quality stereo sound to be send from a A2DP source (the phone) to a A2DP sink (the stereo-headset). In addition to that most A2DP capable devices support the Audio/Video Remote Control Profile support (AVRCP) which allows the mediaplayer to be controlled using the headsets build in buttons.

I've been using both devices for over a month now, mostly for listening to podcasts. So far I'm very pleased with them. The headsets battery last a least a full day with about 3 hours of listening, half an hour of talking and the rest in stand-by. I wasn't expecting anything more of a small necklace like device weighing only 27 grams.
The mediaplayer application on the K610i is definitely more geared towards music and doesn't support podcasts at all, neither does the windows software that came with it. You can create playlists on the phone but those are not saved as files.

In good Sony-Ericsson style the phone is fully standard compliant, supporting the OBEX Object Exchange protocol over Bluetooth, Infrared (IrDA) and USB connections. Among the supported OBEX methods is ObexFTP, obex push and SyncML over OBEX. This is good news for us Linux users since it insures compatibility with free and opensource software.
Browsing files on the phone can be done in 2 ways, Mass-storage device mode or OBEX transfer. Both have advantages and disadvantages.

The mass-storage mode is fast, using the phone as a USB2.0 card reader for the Memory Stick Micro inside. The biggest problem with this approach is that none of the phone functions are available while in mass-storage mode, so no phone-calls or listening to music. Also, on time of writing, the USB mass-storage driver in the ubuntu 6.06 shipped kernel fails to write all blocks to the MSMicro card, resulting a data loss and preventing safe unmounting. This will probably be fixed in more recent kernels.

I use a recent version of OpenObex to transfer podcast episodes to the phone with ObexFTP over USB2.0. This allows all phone functions to be used while transfering files. It is the same method used by the File Manager that's part of the windows software suit. Transfers over OBEX are slower though, just over 1 MB per second. Meaning a 30 MB file, quite common for a podcast would take almost half a minute. This is no problem for me because I use the USB cable to charge the phone and letting it transfer the files while doing other things. But I can imagine the frustration when you would like to quickly transfer a few files before leaving.

I automated the transfer of podcasts to the phone using a Python script found here. In Amarok I copy the files to a temporary folder using the generic mediadevice plugin, after which the script is used as the post-disconnect command (see screenshot). Transfered files are deleted from the tmp folder.

On my todo list is a Java 2 Mobile Edition application for playing audio files that maintains a playlist and a supporting mediadevice plugin. The idea is that played files are removed from the playlist. The Amarok plugin can then delete the old episodes from the phone and mark the as listened in the database.

If anyone want to volunteer for writing the J2ME player, the mediadevice plugin or improving the transfer script, send me a mail at bart [.] cerneels [@] gmail [.] com.

Suggestions are welcome in the comments (moderated for SPAM reasons).

Wednesday, February 28. 2007

KDE4: actions menu Posted by Bart Cerneels in stecchino at 18:33

Comment (1)
Trackbacks (0)

KDE4: actions menu

Sunday, September 24. 2006

actions menu Posted by Bart Cerneels in stecchino at 09:08

Comments (0)
Trackbacks (0)

actions menu

have a "actions" menu in every kde application containing the most common actions you can do with it. When using the desktop menubar the actions menu gets renamed to the application name. See my previous post to see why that is usefull.
Every user is different so it could change the order of the actions menu depending on the users usage of those actions.