DACP in Rhythmbox: Weekly Report 6 & 7

[Alexandre Rosenfeld <airmind gmail com>]

Hi all,

This is my weekly report for Google Summer of Code. For more information about the project, read it here: http://live.gnome.org/SummerOfCode2010/AlexandreRosenfeld_Rhythmbox

I haven't sent my weekly report from last week. I'm very sorry, but I was travelling to get to my parents house last week, as now I'm officially on vacation and the internet here was very bad until a few days ago.

But I haven't stopped working.

- What have I done this week?

I've been looking further into the query problem. Talking to my mentor and a friend at school I was able to rewrite the filter query parser. This means it is now able to correctly parse queries from DACP. It seems stable to me, but further testing also needs to be done.

With that done, I started looking what kind of information the Remote wanted in the query. And the current implementation needs some changes in order to support DACP. In the DAAP plugin and libdmapsharing, some properties names follow the DAAP naming, such as daap.songartist, other follow the Rhythmbox name. In other parts of the code, there is a map between each other, but in the current filter implementation, there is no such map, so only properties named after DAAP will be recognized in the filter. Since DACP uses other properties, this has to be changed and a few other properties must be added (both in libdmapsharing and in the Rhythmbox plugin).

I started looking at optimizations in the filter. I don't like the fact that it does a hash lookup in every record of the db in every query. This means hashing the property name string for every record. A better way would be to hash the property name once and make a way for the record to find a way to discover if that property exist or not. I also thought about a class cache, since all records would probably be of the same class, but I don't think it's worth.

Maybe it doesn't matter either, so I'm trying to find common queries and only seeing the effect in these queries. For instance, some queries might be called many times, so it would be better to build a query model and keep it in memory (which also keeps it updated because the way Rhythmbox works with sources). When to delete these queries is the problem, there is no way to know when it will be asked again.

Also, the code is finally stable enough so that the Remote stays open after it connects to Rhythmbox. Although the correct data is still not being sent (since the filter returns no songs as it doesn't support DACP properties yet), the playlists already show up with their names and number of items.

- What will I do next week?

Next week I plan to finish the properties correctly, either adding a map or using properties names equals to the DAAP query. I need to discover some bugs with signals I'm having. 

I declare a gboolean in the start of the function, set it to TRUE and send it's pointer to a signal handler, but an assertion fails telling me the pointer is NULL. If I add a printf to find the boolean pointer, it's not NULL and the assertion doesn't appear. Probably a problem with compiler optimization that I have no idea how to fix.

- Was my planning accurate?

Not at all. I spent a lot of time understanding DAAP queries. I found out about another DACP server implementation, although it's very different: http://git.debian.org/?p=users/jblache/forked-daapd.git. What was interesting is that it uses ANTLR to parse the query and transform it in to a SQL statement. It was useful to discover more about the syntax, but it was very hard to understand.

- Cool things

ANTLR is cool but way too complex. I used Flex, Byson and YACC before in a class, but I don't remember much about them. I was able to recognize the grammar in ANTLR and it helped me understand the queries. But my code was much shorter and simpler then using a full lexical scanner. I just hope it is as accurate :)

Until next week,

Alexandre