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
The QML side attempted to simply pass all items of type 'Audio' to the
PlaybackManager.playItem(). This does not work for folders and it will
crash. This does not fix the presentation of audio folders/playlists,
but it does fix the crash.
In the ApiClient, the constructor without arguments was used to create a
ClientCapabilitiesDTO. Since this constructor has been made private,
ApiClient now uses the other public constructor to allow the code to
compile once again.
On startup, the DeviceProfile would not be serialized properly to a false
assumption that QJsonValue.toString() returns the JSON representation of
the given value. This now has been fixed by creating a QJsonDocument
converting it to a string.
There were some constructors in the DTOs which allowed construction of
DTO which weren't fully initialized. These constructors have been made
private, as they are still used in the 'fromJson' methods. Additionally,
a constructor with all required parameters to fully initialize the
class has been added.
Additionally, the Loader class has been modified, since it no longer can
assume it is able to default construct the parameter type. The parameter
is now stored as an optional.
Closes #15
Chris Josten
