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.

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

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).

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.

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.

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.

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!