A setting has been added to allow users to select which page should be
opened first. This allows for using Sailfin as a music player
exclusively, as proposed in #34
Special care has been taken to avoid the user being locked out from the
app, for when the library selected as home has been deleted on the
server side. It is real tricky to guide the user to delete dconf keys.
Therefore, a pulley menu with access to settings has been added to all
collection pages and to the unknown page. Additionally, when the setting
is changed, it throws away the entire pagestack and replaces it with the
new home page + the settings page, so the user can always navigate back.
The navigation history of the user will get lost, but otherwise the
implementation gets to complex for a feature that is expected to be used
not that often.
This uses more timers than I hoped for, because otherwise things are
undefined for some reason which I do not know and using timers solves
it. :(
For some reason, the track id was a QDbusObjectPath, but somehow that
caused issues, so I'm breaking the spec and simply changing it to a
string. Now SailfishOS does display the MPRIS controls on the
lockscreen.
Device icons for the local device is now determined by looking at what
the value of the deviceType property of the ApiClient is. This property
was newly introduced, so that applications using JellyfinQt can set
their own device type.
For other devices, a guess is made based on the client name. This guess
has been derived from what Jellyfin Web does.
If the mediaSourceId is not sent, Jellyfin Web will simply not take the
audioStreamIndex and subtitleStreamIndex in account when playing the
media.
A bug also surfaced where the application would crash when playing a
video, playing audio afterwards and then clicking on an item in the now
playing queue. This has also been fixed.
The playback queue is now kept in sync with the playback queue of the
remote jellyfin instance the manager is controlling.
Some additional guards were added in place in the shuffle and playlist
algorithm, since the situation can occur where the now playing index
falls outside of the playing playlist. This happens because when the
an playlist update is received, we need to do another HTTP request
before we know which items are in the queue, while the now playing index
has been updated.
This is a not-optimal way to fix that, but it works well enough for now
and a better solution can be implemented later. (Hello, person in the
future reading the git blame output!)
The PlaybackManager was a giant class that handled UI bindings, fetching
stream URLS, playback logic.
It now has been split up into:
- ViewModel::PlaybackManager, which handles UI interfacing and allowing
to swap out the Model::Playback implementation on the fly.
- Model::PlaybackManager, which is an interface for what a
PlaybackManager must do, handling queues/playlists, and controlling a
player.
- Model::LocalPlaybackManager, which is an Model::PlaybackManager
implementation for playing back Jellyfin media within the application.
- Model::PlaybackReporter, which reports the current playback state to
the Jellyfin server, for keeping track of played items.
- Model::Player, which handles playing back media from an URL and
the usual play/pause et cetera.
In a future commit, this would allow for introducing a
Model::RemoteJellyfinPlaybackManager, to control other Jellyfin
instances.
Deduplicated code in the NarrowAlbumCover and WideAlbumCover.
Additionally, this fixes a bug where the NarrowAlbumCover would behave
wrongly with album covers with an aspect ratio not equal to 1.0.
Resolves #22
I reused the AlbumDetailPage for playlists, as both are very similar. If
they end up being too different, I might want to look into splitting
them up, but for now it will do.
It previously modified the limit for some template instances. That
obviously does not work.
Additionally, setRequestStartIndex and setRequestLimit have been
implemented for GetNextUpParams.
Fixes #19