Wednesday, 16 December 2009

version 0.3.1 released

I've got real-life problems at the moment which are likely to cause problems for a while. So, I'm pushing this out just in case I don't get the chance again. I've tried to make the code as bug-free as possible and made sure the features that work, work.

Differences from 0.2 to 0.3:
  • tagpy dependency gone along with the huge boost-python dep's. In place is Mutagen.
  • File(s) can be added to the playlist directly from the UI using the embedded fileview in tree format.
  • Gone is Phonon. In it's place is Python Gstreamer which, for developing, is a lot more trustworthy.
  • Small UI tweaks. I've disabled non-implemented widgets where suitable and removed some buttons (the searching options buttons in Amarok) that are unlikely to be done for a long time.
  • Massive code refactor. Truth be told, i'm not sure if it's correct but at least the ugly multiple class inheritance has gone and is a lot easier to read than before.
  • Wikipedia info displayed better.The app uses the printable version of each page. Wikipedia seem to be having a massive donation-drive of late so I haven't removed that.
I'm a bit disappointed I didn't get audio-cd playback supported but that is my next thing on the agenda, when I can find the time.


Here's 1 of a few current screengrabs.



If you're wondering why it's 0.3.1, I missed a minor UI bug in 0.3.0.

Monday, 7 December 2009

Mutagen Thoughts

Ok, today i've been working with Mutagen. It's definitely a feature-full package but to my dismay i've notice it's very, very flakey.

The main thing i've noticed, when coming from tagpy, is that Mutagen is extremely picky. I've come across so many instances where mp3/ogg/flac files worked fine in tagpy but not in Mutagen. I feel it's because Mutagen likes to have pristine files with no encoding errors, which frankly is a bit much.
This would be OK if there was some crude method to get around this which requires some hacking about but there's no way. It either works or it doesn't.

I am starting to have my doubts about the switch but the support of aac files, which tagpy lacks, is driving me to figure this issue out.

Sunday, 6 December 2009

Tagging

Currently Gereqi uses tagpy for tagging duties. It's a small and simple tool but sadly is lacking in file format support. This seems to be due to it being a wrapper for taglib so allows a little room for expansion.

There are plenty alternatives out there. Gstreamer has support for tags but documentation for it is elusive. The package I shall be moving to is Mutagen. Quod-libet and Ex-Falso use it. The latter being well-known for it's tagging features.

As I am trying to keep dependencies to a minimum Mutagen is a good choice as it is a needed dependency of libgpod, which somewhere down the line Gereqi will need for iPod support.

So, if I can get around this refactor issue, Mutagen should be coming up soon.

Friday, 27 November 2009

Refactoring

Currently I am in the process of refactoring the code. A class, MainWindow, inherits way too many things and is apparently bad practice. That is not to say it causes performance problems but instead hinders the way things can be added later.

The main problem is that despite understanding the basic proper Class usage I have troubles applying that to the big mess I have created.

Expect a long delay before any new features. Additionally, the Gstreamer move is now complete and all changes are now in the Master branch.

Monday, 23 November 2009

Gstreamer Migration

Just shy of a month ago I became fed up of Phonon's flakey API and decided to dump it for something else. Performance and feature-wise Phonon was OK but thing's in the API didn't actually match up to what was happening in real life. Mainly it's "state" feature was the key reason for me to give it up.
I won't get into details, as it will raise my blood-pressure, but ever since I started using this media-framework I would discover something nasty and create an awful hack to get around it.

Since the end of October I have been trying out Python-Gstreamer in a new git branch. Some periods I doubted my decision because of Python-Gstreamer initially quite terrible documentation. I spent a good period learning the nitty gritty parts of how it uses "elements" to create a "Pipeline" which is a catch-all solution for playing a file.
Despite getting this low-level method to work it was not gap-less. When a track moves tot he next in a playlist automatically, a noticeable gap was present.

This brings me on to Gstreamer's playbin2. If you look at that link you will notice that there is no Python. That's because there is no Python documentation for this useful feature of Gstreamer. Playbin2 is a high-level solution to playing a file. You can put in elements if you want but I wanted it just for it's gap-less playback.
As I had no Python examples a Google search resulted in this find. It took a while to figure out what was relevant to Gstreamer and Quod-libet but eventually I got the gist of it. If it looks messy, that is OK. It looked the same to me. In my opinion they seem to be doing a lot of unnecessary things such as destroying+re-creating their playbin2 object when loading a new file. I know how this sounds but I think it looks very hacked together. Maybe time will prove them right and me to be wrong.

By taking what I needed from quod-libet's backend I ended up with an almost working solution. On rare occasions gap-less playback was possible. After a frustrating and fruitless few days I made a new thread at Gentoo Forums as last resort. Thankfully a superstar by the name of didumos provided a possible reason to the error, investigated it, and provided a patch. All that and he/she doesn't _do_ Python.

Since then I have done a touch of bug-fixing and now believe the end is near for the migration. I have a feeling a few bugs are present in my use of gstreamer and defintely know it's not optimal. In addition PyLint always crashes when checking it's "Pythonness" of the backend which isn't helpful.

After this a few new minor features expect ver0.3 out soon.

Blog.__init__()

As it's a pain to manually mess around with the Github static page I thought i'd create a dev page so that it appears i'm actually doing/ thinking about something. Although I am making progress, unless you watch the github repository you'll rarely hear anything about it other than a slight mention in Reddit.

Basically this blog is just to track the development of Gereqi and for any users to express their views/ideas on this application.