Panflute fails to display song information with non-latin letters in file name

Forgot to attach output. From applet.stderr:

  File "/usr/lib/python2.6/dist-packages/panflute/applet/widget.py", line 378, in do_destroy
    if self.__update_source is not None:
AttributeError: 'MetadataScroller' object has no attribute '_Scroller__update_source'

I don't think this necessarily has anything to do with non-Latin characters in metadata, but it is definitely related to the attempted fix to lp:476500.

The root cause of this seems to be that overriding do_destroy caused the handler to somehow get run even after the object was completely destroyed. I replaced it with an destroy signal handler, and that seems to have fixed the problem.

Panflute still hangs on characters like Я. So it doesn't really seem fixed (using the latest r293 of course)

OK, then the exception trace and the non-Latin thing are two separate problems, and the last check-in only fixed the former.

I forgot to ask: which player are you using, and which version? The problem is most likely in the handling on non-Latin characters from that particular player.

I use Rhythmbox 0.12.5 on Ubuntu Karmic x86_64. I know that this has worked nicely in music-applet (just checked with 2.5.0).

I just tried it with Banshee 1.5.1 and it seems to work with no problems in Panflute.

This could be an instance of lp:483120, where a song with malformed metadata causes exceptions to get thrown, resulting in the daemon and applet getting out of sync with each other. Try the latest trunk and see if that solves the problem.

If not, try this: Remove the applet from the panel, kill any panflute-daemon that may be running, start it from the command line with the -d (debug) flag, and then reload the applet and reproduce the problem. The daemon's debugging output should indicate where the problem is occuring. I couldn't reproduce the problem with the songs with non-Latin characters in my Rhythmbox library.

It didn't solve the problem, so here's the output (see panflute-deamon-1)

It still doesn't seem to be fixed unfortunately. Even though it works with Banshee on the very same files, it doesn't with Rhythmbox (using r295 of panflute).

Can you tell me what Rhythmbox is reporting as the song's cover art file? Do the following at the command line, when Rhythmbox is paused on a song that triggers this bug:

1. dbus-send --session --print-reply --dest=org.gnome.Rhythmbox /org/gnome/Rhythmbox/Player org.gnome.Rhythmbox.Player.getPlayingUri

2. dbus-send --session --print-reply --dest=org.gnome.Rhythmbox /org/gnome/Rhythmbox/Shell org.gnome.Rhythmbox.Shell.getSongProperties string:'file:///the/uri/that/step/one/returned'

The second command will dump a lot of stuff; look for rb:coverArt or rb:coverArt-uri in the output. That will be the location of the artwork triggering the bug. (In particular, Python's URL libraries don't play nicely with the non-8-bit strings Rhythmbox sometimes returns.)

This:
      dict entry(
         string "rb:coverArt-uri"
         variant string "/home/soeb/.cache/rhythmbox/covers/KoЯn - Greatest Hits Vol. 1.jpg"
      )

Although I think this time I might have checked wrong. For some reason after rebooting it all works perfectly and without any problems. So I think it fortunately is fixed now. Thanks!

That's good to hear. The reboot "fixed" the problem of the old panflute-daemon still running even after you installed the newer version. It's important to remove the applet from the panel before trying to kill panflute-daemon too, since the applet will immediately try to restart it. (I've been burned by this a few times myself.)