I will summarize my findings and provide some evidence to illustrate the redundant network request process of Infuse.
Background
I am using an emby server provided by a third party, and I used the direct mode of Infuse when adding the server.
My device is Iphone and IPad.
Issue
- Redundant requests exist when playing videos.
When clicking to play a video, Infuse needs to use /Videos/{Id}/stream
to fetch data, which requires obtaining a crucial parameter MediaSourceId
.
Let’s see how Infuse does it:
- GET
Item/{itemId}/PlaybackInfo
- GET
Users/{userId}/items/{itemId}
- GET
Users/{userId}/items/{itemId}
- GET
Videos/{Id}/stream
Requests 2 and 3 are identical, meaning Infuse makes redundant requests. Moreover, requesting items is not necessary for playing videos, as the PlaybackInfo
already includes the MediaSourceId
.
When entering the video details page, Infuse retrieves the episode information of the video. This is done using the endpoints Shows/{episodeId}/Episodes and Shows/{seasonId}/Seasons. These endpoints already include the
MediaSourceId
for each video. Theoretically, Infuse could directly call Videos/{Id}/stream when clicking to play a video.
- Constant metadata refresh
Infuse is constantly updating the metadata of videos, triggered by any condition such as loading a video, returning to the video details page after finishing playback, or going back to the homepage (even if it was just updated a minute ago). Normally, while playing a video or on the video details page, I am no longer concerned about the metadata of other videos. Even if Infuse wants the latest metadata, as mentioned, it updates upon returning to the homepage.
- Video cache cleared after locking the screen
Typically, Infuse keeps caching an entire film to ensure smooth playback. However, when the screen is locked, Infuse immediately clears all video caches, even if you unlock the device a second later. This results in all video data needing to be reloaded, following the request logic described in issue 1.
Evidence
I provided a long screenshot to reflect the issue. The long screenshot shows the network request situation of Infuse after clicking the play button, captured by a packet-sniffing tool, with the request sequence being from bottom to top.
First, I clicked to play a video with the ID 2373245. As described earlier, Infuse, through playbackInfo
, redundantly requested item
twice, and then began to play the video via stream
. The ID for item
remained the same, confirming that Infuse has redundant requests. Moreover, as emphasized earlier, requesting item
is not necessary for playing the video.
In addition, even though I was already playing the video, Infuse continued to update metadata information, as evidenced by the ongoing requests for episodes and seasons. It is important to note that I was using a direct mode.
Explanation
You might ask: Why should I care about these additional network requests when they usually complete in milliseconds?
I would like to respond by saying:
Firstly, Infuse, an app refined over many years, should not have these issues.
Secondly, I have also received complaints from users about slow video loading on Infuse when using third-party Emby services, which often require international network requests. This can lead to request times of several seconds or even more than ten seconds during network congestion, resulting in a delay of over 30 seconds from clicking play to the start of the video. Infuse needs to consider users in areas with weak network connections.