GitLab

Podcast refcount issues

See merge request !98

The primary user of 'RBPodcastChannel' during podcast search is the
search result feed model. So, we refcount it inside
insert_search_result (), which adds entries to the feed model, rather
than in other places.

We don't store the error in the parse data any more, so this was
probably checking the wrong thing, besides being a bit hard to read.

The podcast add dialog feed model takes a reference to the parse result
when it gets inserted directly.

Fix keyboard shortcuts not working sometimes

See merge request !94

Ignore key modifiers which are valid, but not significant as keyboard
accelerators for a GTK application. This would include num lock, caps
lock etc. This should fix issues of rhythmbox shortcuts not working
sometimes.

tests: replace deprecated fail_unless / fail_if calls

Closes #1803

See merge request !70

Closes: #1846 again

faac doesn't seem to be available in many distributions any more,
replaced by voaacenc in some places, fdkaacenc in others.
fdkaacenc has a bitrate property, but its maximum value is G_MAXINT
which doesn't work with the property editor (yet?) so that isn't
made available yet.

Search results can be deleted from the podcast add dialog while still being
parsed, which presents the opportunity for a use after free.  Rather than
making the main thread wait for parsing to hit a cancellation point before
freeing the data structure, it's easier to reference count it.

Closes: #1846

Closes: #1845

rhythmbox-client: flush dbus connection to send the 'quit' message before process exit

See merge request !88

This was an issue in single core / uniprocessor / VMs, where
rhythmbox-client process exits due to 'exit()' call, before the 'quit'
message is sent to the rhythmbox instance.

Also refer: glib#2284

If the stream isn't currently linked, we won't get anything useful
by querying the pipeline position, instead query the stream.

If the stream doesn't even have a decoder pad yet, we can't try to
play it, so instead wait for preroll to finish.

If the stream is already buffered when preroll finishes, waiting
for buffering to finish after that won't get us anywhere.

In some situations this can be called concurrently on two threads,
so it needs more protection.

If we get a Requested Range Not Satisfiable response, we can't
resume a partial download, so we have to retry from the start.
Some podcast hosts do this despite advertising support for range
requests.

all: Update application ID to org.gnome.Rhythmbox3

See merge request !57