[Rhythmbox-devel] DACP in Rhythmbox: Weekly Report 8
- From: Alexandre Rosenfeld <alexandre rosenfeld gmail com>
- To: "gnome-soc-list gnome org" <gnome-soc-list gnome org>, "W. Michael Petullo" <mike flyn org>, rhythmbox-devel <rhythmbox-devel gnome org>
- Subject: [Rhythmbox-devel] DACP in Rhythmbox: Weekly Report 8
- Date: Fri, 16 Jul 2010 23:06:19 -0300
Hi all,
As usual, this is my weekly report. More information about my project
is available here
http://live.gnome.org/SummerOfCode2010/AlexandreRosenfeld_Rhythmbox
- What have I done this week?
This week was very productive. While I´m on vacation, I still have one
recuperation exam next week and I´ll be studying this weekend, so I
spent a lot of time on my project this week to get my weekend free.
I started by rewriting the filter function, which is responsible of
filtering possible entries in the DB that match a query (as last week
I rewrote the query parser to fit DACP). This couldn´t handle DACP
either, because it couldn´t handle properties other then strings and
other properties that wasn´t mapped to their DAAP names (this portion
of the code was very incomplete and kind of hard-wired to what it was
able to handle).
I started experimenting with exposing a metadata map from DMAP
properties into a enum. This required DMAPRecord to add one more
function able to handle this enum. It was faster then before, but my
mentor showed me some issues with this implementation and I started
again, refining the old code. This time I changed DMAPRecord property
names into their DMAP equivalent, using only the last part of the
name, ignoring everything before the last dot. I also added support
for other properties using GValue transformation and a few specific
handlers, when GValue transformation might not be consistent (numbers
and booleans for instance). This should handle known properties fine
and be generic enough for future properties (also it should not crash
on unknown types, which was something my mentor pointed out).
This turned out be a good implementation (altough I still think it´s
slow, not sure if it is too slow for production) and it should work.
However, after hours of debugging, something really weird is
happening, so that all the records filtered dont appear correctly in
the hash table when it goes to the artist-tabulator. I´ve checked the
code many times, checked many breakpoints and added test code, I don´t
know what is the problem yet.
I decided to take a break and go into the signals I added in the
beginning of the project but never implemented in libdmapsharing or
Rhythmbox. This required a refactoring of the DACP code in Rhythmbox,
since this would add too much unrelated code to daap-plugin.c. After a
few architecture considerations this was done and working again.
So I added the main signal, play-status-update, which sends "Now
Playing" data to the Remote. To my rejoice, after long hours of
debugging and bug fixing, the Remote shows the currently playing
track, with the current time that get´s correctly updated. All the
actions are missing, such as play/pause, but that will come shortly.
What is strange is that the actions don´t fire unhandled paths yet, so
maybe some key path is not being handled which makes the Remote not
call the other parts. A mistery to be solved next week.
- What will I do next week?
The filter code is ready but the bug affecting the records not being
correclty present afterwars must be fixed (somehow, they are not
objects anymore. Hm, just reminded me they might be getting freed
prematurely).
Also more control points will be implemented. This is tedious but
straightfoward, add path handlers to DACPShare, emit signals, connect
to signals in Rhythmbox and call RBShellPlayer.
A bit more complicated might be the code to handle the currently
playing playlist, but I´m not sure I´ll have the time for that this
week.
- Was my planning accurate?
Yes, I finished the filter code and the properties handler.
I fixed the signal bug, I was passing only the return parameter and
forgot it took one more parameter, so the return parameter was indeed
NULL.
- Cool things
I should trust assertions more, but they never show me the real cause
of the problem.
Coding in C and GObject is giving me a lot of headaches trying to hunt
bugs, fortunately I found out that the Anjuta debugger is very useful
and I´ve been using it a lot.
Git was very useful reverting my experimental code. Another big
advantage of commiting often and keeping commits more objectives. By
the way, I don´t have internet in my laptop for a while, so I haven´t
pushed my changes for a few days.
Until next week,
Alexandre
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]