Tuner lock up when iOS app crashes

[tree2369 16]

Shared a few crashes via the TestFlight with my iOS app crashing while trying to change quality setting while viewing a channel.

 

A by product of this is that Emby seems to 'hold' the tuner, even once it has disappeared from the dashboard. This is similar to long running issue Plex had with tuners locking up and @sa2000 did a great job at getting the ball rolling with the fix for that, who I see is doing some bug investigation at emby now.

 

I have since moved over to Emby and am now re-encountering the issue. I have a fairly consistent way of reproducing the tuner lock, so I can send in a log file if the TestFlight diagnostics are no good?

 

Thanks 

[sa2000 674]

2 hours ago, tree2369 said:

Shared a few crashes via the TestFlight with my iOS app crashing while trying to change quality setting while viewing a channel.

Hi

Trying to find out from the devs what has been received

 

2 hours ago, tree2369 said:

I have a fairly consistent way of reproducing the tuner lock, so I can send in a log file if the TestFlight diagnostics are no good?

The testflight data would hopefully help with the ios app crash. Are there repro steps for the crashes?

I do not expect the Testflight diagnostics to help with the second issue - of the emby server ending up with the locked tuner.  I do not know what timeouts there are in Emby Server for tuner live tv sessions but emby server debug logs coinciding with the time of the emby ios app crash would help - I think there would also need to be logs captured say 20 minutes later to see if there were any timeouts. There would also be ffmpeg logs together with the embyserver logs

Logs can be downloaded - cleaned of tokens / api keys using the emby web server settings logs interface. But please do enable debug logging beforehand and restart the server before reproducing the problem so that there would be complete set of debug logs.

 

[tree2369 16]

4 hours ago, sa2000 said:

Hi

Trying to find out from the devs what has been received

 

The testflight data would hopefully help with the ios app crash. Are there repro steps for the crashes?

I do not expect the Testflight diagnostics to help with the second issue - of the emby server ending up with the locked tuner.  I do not know what timeouts there are in Emby Server for tuner live tv sessions but emby server debug logs coinciding with the time of the emby ios app crash would help - I think there would also need to be logs captured say 20 minutes later to see if there were any timeouts. There would also be ffmpeg logs together with the embyserver logs

Logs can be downloaded - cleaned of tokens / api keys using the emby web server settings logs interface. But please do enable debug logging beforehand and restart the server before reproducing the problem so that there would be complete set of debug logs.

 

Will try get some time later in the week to capture some server logs to go along with the TestFlight diagnostics.

 

My way of reproducing the crash 90% of the time is loading any TV channel on Auto quality selection, and then try to change it to something else while viewing the video.

This seems to crash the app but leave it in the background. Most of the time the app won’t load up again unless you force close the app, this is when the “session” disappears from the dashboard - but if you look at your tuner status (whether it be HDHR or xteve/threadfin or another I’ve used is ADBTuner) it will be locked/still in use.

 

Sometimes you can then go back into the stream to continue viewing, but it remains locked on and exiting the stream from then on has no impact on the tuner status.

[tree2369 16]

On 30/07/2024 at 18:54, sa2000 said:

Hi

Trying to find out from the devs what has been received

 

The testflight data would hopefully help with the ios app crash. Are there repro steps for the crashes?

I do not expect the Testflight diagnostics to help with the second issue - of the emby server ending up with the locked tuner.  I do not know what timeouts there are in Emby Server for tuner live tv sessions but emby server debug logs coinciding with the time of the emby ios app crash would help - I think there would also need to be logs captured say 20 minutes later to see if there were any timeouts. There would also be ffmpeg logs together with the embyserver logs

Logs can be downloaded - cleaned of tokens / api keys using the emby web server settings logs interface. But please do enable debug logging beforehand and restart the server before reproducing the problem so that there would be complete set of debug logs.

 

Okay.

 

So the sequence of events for these logs and pictures are:

1. Load ch9 (90) on iOS Emby app, change quality twice to produce a crash

2. Load ch7 (70) on iOS Emby app, change quality twice to produce the same crash.

3. View HDHR tuner Status web page - both tuners still in use.

4.  Try to load ch10 on iOS Emby app, loads the buffer 'stream limit' image from thread fin.

5. Check threadfin(xteve) logs that I run my HDHR through (to bwdif=1 deinterlace), says the tuner limit was reached on the last channel tune attempt.

 

In the 5 or so minutes since finishing those steps and writing this, the tuners are still listed as in use according to the HDHR tuner status webpage, but are not where to be seen on the Emby dashboard.

embyserver-2.txt

 

[sa2000 674]

Thanks @tree2369for the detail and the debug log covering the whole sequence. I have referred this to the development team. i do see the ffmpeg session being terminated so this is not a stuck transcoder process issue.

[sa2000 674]

On 30/07/2024 at 09:26, tree2369 said:

Shared a few crashes via the TestFlight with my iOS app crashing while trying to change quality setting while viewing a channel.

The cause of the crash has been identified and is being fixed.

[tree2369 16]

2 hours ago, sa2000 said:

Thanks @tree2369for the detail and the debug log covering the whole sequence. I have referred this to the development team. i do see the ffmpeg session being terminated so this is not a stuck transcoder process issue.

I did notice that post resetting my HDHR and releasing the channels, that if I went to load up one of the channels I had loaded (ch90 or ch70), that Emby still thought it had some sort of buffer or that it was still loaded. It wasn’t until I restarted the server after the lock up that I was able to load those ‘locked up’ channels.

 

2 hours ago, sa2000 said:

The cause of the crash has been identified and is being fixed.

The cause of specifically the iOS crash? That’s great! Always on the ball mate!

[Luke 42077]

Hi, please let us know how things compare with Emby for iOS 2.2.27. Thanks !

[tree2369 16]

46 minutes ago, Luke said:

Hi, please let us know how things compare with Emby for iOS 2.2.27. Thanks !

Sent a crash log via the TestFlight.

Starting on ‘Auto’ I could change to 720p - 4mbps’ and then to ‘1080p - 4mbps’ without crash, but then changing back to auto caused the app to crash.

 

Will do some more testing at home when I can reset all the tuners easier.

 

Cheers

Edited August 4, 2024 by tree2369

[Luke 42077]

@tree2369are you still able to reproduce the crash with Emby for iOS 2.2.28?

[tree2369 16]

Still crashing as of the latest Emby iOS beta 2.2.30(1)

[sa2000 674]

On 21/09/2024 at 15:15, tree2369 said:

Still crashing as of the latest Emby iOS beta 2.2.30(1)

Have you submitted crash feedback ? Send your Apple ID in forum Private Message and the devs can check for any crash reports 

Alternatively, on the iOS device, go to Settings / Privacy & Security / Analytics & Improvements / Analytics Data and see if you can find ips files that match the times of your app crashes, Copy these out and zip and make available.  Emby app crashes would have the "Emby" in the filename - unless it is force kill by iOS eg memory/cpu use, in which case it would be a JetsamEvent ... filename