[CoreELEC] Kodi freeze when stop the played video #728
Comments
|
Looks like the CoreElec specific code tries to read / write to the sys fs most likely race when changing refreshrates, see: Sorry - this code is not in kodi at all anymore, please continue in the coreelec forum. The error should go away when you plain disable AML in the settings, right? |
|
can you explain me how to disable AML? |
|
@vpeter4 sorry for ping you, have you some suggest? |
|
This particular AML related code was written a long time ago, I suppose, and there is no check to verify whether the sysfs exists at all before trying to read it. This is an optional or depricated sysfs entry that doesn't exist. It should not affect anything, or cause the above mentioned problem. |
|
Because CoreELEC is using modified Kodi code it is not supported here. Try the addon on some supported platform (like LE on Raspberry Pi). And fyi, on testing the solution with TLS alignment requirement on arm for libewidevine some of us noticed similar issue you describe. Sometimes we could play and stop a movie from Netflix for 100 times without a problem but sometimes some described problems happen. You could try some older CE release without TLS patch and using old libvidewine if there would be any difference (we didn't do that). |
|
i have only this arm device to make tests |
|
This is a GDB debug log and it shows a memory error of the addon cause a freeze of kodi.bin. When kodi does freeze the CDMMessage is not arriving anymore. GDB log: |
|
yes could be |
|
Maybe something to do with the changes in #589 ? |
|
This is a bit strange (from #589): IMO there should be no blocking of the thread when it will be disposed, |
|
You need to get sure the session is still active and accessible until this CDM message arrived. Also I have no idea about the exported function: I can hit this error sometimes on first attempt, sometimes after 10 or 15 times. "Best" results I got with Amazon VOD + the movie Bliss. Just start, play 1-2 seconds and hit "x" on keyboard to stop playback. |
|
The original purpose of 589 was just for YouTube movies but I think now since a more recent cdm update the license renewal is used by a lot more by default. @matthuisman I remember you mentioning something about this, can you jump in? If you examine the PR thread the code for licenserenewal always existed (commented out the function call) but enabling it would cause crash on stop video. Additional changes were introduced to mitigate the crash but from the looks of it a more proper solution may be needed. |
|
I got some more time and this "hack" does fix it. It is not solved properly and it's not finished. It's just to show a difference and it make a proof of concept that the dispose of the session cause this issue. I tried it now 35 times without any kodi freeze. I never got so far, but maybe I was just lucky. The timer loop So here: Edit: diff --git a/lib/libbento4/Core/Ap4CommonEncryption.h b/lib/libbento4/Core/Ap4CommonEncryption.h
index 042ac04..3a81ab2 100644
--- a/lib/libbento4/Core/Ap4CommonEncryption.h
+++ b/lib/libbento4/Core/Ap4CommonEncryption.h
@@ -523,6 +523,7 @@ public:
virtual AP4_UI32 AddPool() { return 0; };
virtual void RemovePool(AP4_UI32 poolid) {};
virtual const char* GetSessionId() { return NULL; };
+ virtual void CloseSessionId() {};
virtual AP4_Result DecryptSampleData(AP4_UI32 poolid,
AP4_DataBuffer& data_in,
diff --git a/wvdecrypter/wvdecrypter.cpp b/wvdecrypter/wvdecrypter.cpp
index b3f37fa..3ed2b1b 100644
--- a/wvdecrypter/wvdecrypter.cpp
+++ b/wvdecrypter/wvdecrypter.cpp
@@ -174,6 +174,7 @@ public:
void GetCapabilities(const uint8_t* key, uint32_t media, SSD_DECRYPTER::SSD_CAPS &caps);
virtual const char *GetSessionId() override;
+ virtual void CloseSessionId() override;
void SetSession(const char* session, uint32_t session_size, const uint8_t *data, size_t data_size)
{
std::lock_guard<std::mutex> lock(renewal_lock_);
@@ -477,8 +478,7 @@ WV_CencSingleSampleDecrypter::WV_CencSingleSampleDecrypter(WV_DRM &drm, AP4_Data
if (keys_.empty())
{
Log(SSD_HOST::LL_ERROR, "License update not successful (no keys)");
- drm_.GetCdmAdapter()->CloseSession(++promise_id_, session_.data(), session_.size());
- session_.clear();
+ CloseSessionId();
return;
}
Log(SSD_HOST::LL_DEBUG, "License update successful");
@@ -487,7 +487,7 @@ WV_CencSingleSampleDecrypter::WV_CencSingleSampleDecrypter(WV_DRM &drm, AP4_Data
WV_CencSingleSampleDecrypter::~WV_CencSingleSampleDecrypter()
{
if (!session_.empty())
- drm_.GetCdmAdapter()->CloseSession(++promise_id_, session_.data(), session_.size());
+ CloseSessionId();
drm_.removessd(this);
free(subsample_buffer_decrypt_);
free(subsample_buffer_video_);
@@ -573,6 +573,27 @@ const char *WV_CencSingleSampleDecrypter::GetSessionId()
return session_.empty()? nullptr : session_.c_str();
}
+void WV_CencSingleSampleDecrypter::CloseSessionId()
+{
+ Log(SSD_HOST::LL_DEBUG, "%s: enter", __func__);
+
+ if (!session_.empty())
+ {
+ Log(SSD_HOST::LL_DEBUG, "%s: CloseSessionId: %s", __func__, session_.c_str());
+ drm_.GetCdmAdapter()->CloseSession(++promise_id_, session_.data(), session_.size());
+ session_.clear();
+ }
+
+ int i = 0;
+ while (i < 10)
+ {
+ i++;
+ std::this_thread::sleep_for(std::chrono::milliseconds(100));
+ }
+
+ Log(SSD_HOST::LL_DEBUG, "%s: leave", __func__);
+}
+
void WV_CencSingleSampleDecrypter::CheckLicenseRenewal()
{
{
@@ -1418,7 +1439,10 @@ public:
virtual void DestroySingleSampleDecrypter(AP4_CencSingleSampleDecrypter* decrypter) override
{
if (decrypter)
+ {
+ decrypter->CloseSessionId();
delete static_cast<WV_CencSingleSampleDecrypter*>(decrypter);
+ }
}
virtual void GetCapabilities(AP4_CencSingleSampleDecrypter* decrypter, const uint8_t *keyid, uint32_t media, SSD_DECRYPTER::SSD_CAPS &caps) overrideFiltered log: |
|
@glennguy |
|
😕 it looks like still freezing sometimes. It does happen when the CDMMessage 4 on CloseSession does not arrive. Edit: Edit 2: Here the addon for Netflix users with PR725 included: |
|
I ran a Netflix plan: standard These are my findings:
This Kodi log from the test device is available for review and study. Be advised the log will auto destruct one month from date of posting. |
|
I would like to understand what happened |
|
The ISA provided are for testing purposes, the one with the PR725 included was added to allow users trying in Netflix to have 1080p. The fix is not related to PR725. Once confirmed working well (as it seems) a PR can be created. |
i think the PR725 code speak itself the only thing different is here: |
|
@CastagnaIT further tests indicated that also freeze in amazon is gone and the PR was submitted, it's #729 . So #725 and #729 merges would fix known problems. Been running an ISA with both PR's in the last two days. |
|
thanks i have just tried to play about 20 videos without problems with 729 with combined an improved 725 |
|
Fixed in #729 |
|
@glennguy @Portisch I have custom built Kodi for a Rockchip Rk3328 device and am seeing this similar error... here's relevant excepts from the kodi log an gdb trace. I have to assume the issue is the version of widevine that got auto installed? The CPU is armv8, and the build is using a 64-bit kernel, but the userspace and kodi binary are compiled for 32-bit. Maybe I need to patch the inputstream helper to download a different widevine? Any and all feedback is greatly appreciated! INFO : CAddonMgr::FindAddons: inputstream.adaptive v19.0.0 installed |
|
Update - looks like my original commit to inputstream helper was lost over time :( I'll submit it... again... |
|
Another update: unfortunately I've been unable to get this to work. Everything I've tried has come up with the exact same errors as I listed above. @Portisch @glennguy would greatly appreciate ideas and thoughts on what to try. Some initial questions.... does the kernel now require relocation enabled in order to support widevine? The relr.dyn assembly part of the kernel gets adjusted when relocation is enabled (it's off in my build). I've tried manually implementing 3 different compatible widevine builds from this list, all return the same errors I put above: I know this is a closed issue, but even if widevine doesn't load I assume the intent is not to completely crash kodi, so this bug technically still exists in some form and should probably be re-opened. |
"custom built" != official Kodi - so don't expect the same levels of support. Please stop tagging devs and bumping old issues. Good luck! |
|
:) first, thanks so much for the reply!
I understand what custom means haha and as such I don’t expect the same level of support. As I explained, I did attempt to resolve on my own before posting, and will continue to do so. To clarify, I wasn’t expecting someone to reply with a solution. Just share ideas on more things for me to try on my own. The core of open source IS collaboration after all.
That being said, I also thought the authors might want to know this issue may possibly still exist. I could have opened a new issue, but i expected it could have been labeled as duplicate and closed, which is why I am commenting here on this older thread. Seemed like a logical place to start, right? :D
Of course I’ll continue working on it on my own as well.
Thanks for the link! I see I'm on the right track with the relocation, I'll try some of those suggestions!
Any additional thoughts and suggestions welcome.
- Mr.FixIt
… On Oct 25, 2021, at 5:58 PM, Matt Huisman ***@***.***> wrote:
I have custom built Kodi for a Rockchip Rk3328
"custom built" != official Kodi - so don't expect the same levels of support.
Custom builds will often need custom fixes / workarounds
Please stop tagging and bumping old issues.
You'll need to go do some work and look at what other platforms have done to support the latest widevine
Start here: #678
Good luck!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
|
dobo90
pushed a commit
to dobo90/inputstream.adaptive
that referenced
this issue
Feb 14, 2023
…hile CloseSession is active to avoid endless loop.
Sometimes when stopping a playback Kodi crashes with a following backtrace:
(__m=<optimized out>, this=<optimized out>)
at /usr/include/c++/12.1.0/bits/atomic_base.h:486
__b = <optimized out>
at /usr/include/c++/12.1.0/atomic:87
(adp=std::shared_ptr<media::CdmAdapter> (use count 1, weak count 1) = {...}, delay=<optimized out>, context=<optimized out>)
at /usr/src/debug/kodi-addon-inputstream-adaptive/inputstream.adaptive-20.3.3-Nexus/wvdecrypter/cdm/media/cdm/cdm_adapter.cc:81
at /usr/include/c++/12.1.0/bits/invoke.h:96, unsigned long long, void*), std::shared_ptr<media::CdmAdapter>, long long, void*> >::_M_invoke<0u, 1u, 2u, 3u>(std::_Index_tuple<0u, 1u, 2u, 3u>)
(this=<optimized out>) at /usr/include/c++/12.1.0/bits/std_thread.h:252
at /usr/include/c++/12.1.0/bits/std_thread.h:259
at /usr/include/c++/12.1.0/bits/std_thread.h:210
at /usr/src/debug/gcc/libstdc++-v3/src/c++11/thread.cc:82
ret = <optimized out>
pd = 0x85cf9080
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {857629366, 66004830, -2049994624, -2008033272, -2008033282, 338, -2008033281, 8387456, -2058383360, -2049995908, 1920, 1080, 3840, 2160, 0, 10000000, -1431355392, 1107558643, 0 <repeats 46 times>}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
robust = <optimized out>
After searching in the github history it came out that there was a
similar issue adressed in xbmc#728.
For some reason that piece of code got removed in
xbmc@8889fe9
(in pull request xbmc#883).
The stack trace is from the Raspberry Pi 4 machine. But I can also reproduce the issue
on my x86_64 Linux machine by adding a 1s sleep in the beginning of CdmAdapter::SetTimer.
In order to reproduce it is necessary to quickly play/stop streams.
Script attached at the end of the commit message can be used to ease the reproduction.
In my environment running the script for 1-3 minutes makes Kodi crash.
Although the root cause described in xbmc#729
was a busy loop. Right now address sanitizer reports:
```
AddressSanitizer:DEADLYSIGNAL
=================================================================
==108079==ERROR: AddressSanitizer: SEGV on unknown address 0x7f6e314f7d4a (pc 0x7f6e314f7d4a bp 0x7f6e263fd830 sp 0x7f6e263fd720 T464)
==108079==The signal is caused by a READ memory access.
==108079==Hint: PC is at a non-executable region. Maybe a wild jump?
#0 0x7f6e314f7d4a (<unknown module>)
xbmc#1 0x7f6e3151c066 (<unknown module>)
xbmc#2 0x7f6e31526947 (<unknown module>)
xbmc#3 0x7f6e31526729 (<unknown module>)
xbmc#4 0x7f6e31526620 (<unknown module>)
xbmc#5 0x7f6e315265a1 (<unknown module>)
xbmc#6 0x7f6e31526585 (<unknown module>)
xbmc#7 0x7f6e46ed72c2 in execute_native_thread_routine /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/thread.cc:82
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (<unknown module>)
Thread T464 created by T51 here:
#0 0x7f6e49464207 in __interceptor_pthread_create /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_interceptors.cpp:207
xbmc#1 0x7f6e46ed73a9 in __gthread_create /usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/gthr-default.h:663
xbmc#2 0x7f6e46ed73a9 in std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/thread.cc:147
xbmc#3 0x7f6e31522028 (<unknown module>)
xbmc#4 0x7f6e27569d40 (/home/dobo/.kodi/cdm/libwidevinecdm.so+0x969d40)
xbmc#5 0x7f6e2757e7fc (/home/dobo/.kodi/cdm/libwidevinecdm.so+0x97e7fc)
xbmc#6 0x7f6e27569c36 (/home/dobo/.kodi/cdm/libwidevinecdm.so+0x969c36)
xbmc#7 0x7f6e3151fb28 (<unknown module>)
xbmc#8 0x7f6e3151c0b1 (<unknown module>)
xbmc#9 0x7f6e31526947 (<unknown module>)
xbmc#10 0x7f6e31526729 (<unknown module>)
xbmc#11 0x7f6e31526620 (<unknown module>)
xbmc#12 0x7f6e315265a1 (<unknown module>)
xbmc#13 0x7f6e31526585 (<unknown module>)
xbmc#14 0x7f6e46ed72c2 in execute_native_thread_routine /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/thread.cc:82
Thread T51 created by T45 here:
#0 0x7f6e49464207 in __interceptor_pthread_create /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_interceptors.cpp:207
xbmc#1 0x7f6e46ed73a9 in __gthread_create /usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/gthr-default.h:663
xbmc#2 0x7f6e46ed73a9 in std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/thread.cc:147
xbmc#3 0x7f6e31522028 (<unknown module>)
xbmc#4 0x7f6e27569d40 (/home/dobo/.kodi/cdm/libwidevinecdm.so+0x969d40)
xbmc#5 0x7f6e2757e7fc (/home/dobo/.kodi/cdm/libwidevinecdm.so+0x97e7fc)
xbmc#6 0x7f6e2757e70e (/home/dobo/.kodi/cdm/libwidevinecdm.so+0x97e70e)
xbmc#7 0x7f6e274e4ecc (/home/dobo/.kodi/cdm/libwidevinecdm.so+0x8e4ecc)
xbmc#8 0x7f6e3151f280 (<unknown module>)
xbmc#9 0x7f6e314e9ea1 (<unknown module>)
xbmc#10 0x7f6e314e49bb (<unknown module>)
xbmc#11 0x7f6e314f45ce (<unknown module>)
xbmc#12 0x7f6e2889228f in SESSION::CSession::InitializeDRM(bool) /home/dobo/kodi/inputstream.adaptive/src/Session.cpp:643
xbmc#13 0x7f6e28893279 in SESSION::CSession::InitializePeriod(bool) /home/dobo/kodi/inputstream.adaptive/src/Session.cpp:723
xbmc#14 0x7f6e2888e36d in SESSION::CSession::Initialize() /home/dobo/kodi/inputstream.adaptive/src/Session.cpp:266
xbmc#15 0x7f6e28775f4c in CInputStreamAdaptive::Open(kodi::addon::InputstreamProperty const&) /home/dobo/kodi/inputstream.adaptive/src/main.cpp:101
xbmc#16 0x7f6e287871a1 in kodi::addon::CInstanceInputStream::ADDON_Open(AddonInstance_InputStream const*, INPUTSTREAM_PROPERTY*) (/usr/lib/kodi/addons/inputstream.adaptive/inputstream.adaptive.so.20.3.2+0x3871a1)
xbmc#17 0x55c2811f4ddc in CInputStreamAddon::Open() (/usr/lib/kodi/kodi.bin+0xb66ddc)
Thread T45 created by T0 here:
#0 0x7f6e49464207 in __interceptor_pthread_create /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_interceptors.cpp:207
xbmc#1 0x7f6e46ed73a9 in __gthread_create /usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/gthr-default.h:663
xbmc#2 0x7f6e46ed73a9 in std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/thread.cc:147
```
The root cause of the crash is unknown as it comes directly from
libwidevine library. But it crashes when we call cdm->TimerExpired when
the session is closed. After applying mentioned commit I'm not able
to reproduce the crash anymore.
Script to reproduce the issue:
```
set -x
URI='Change it to some uri to play'
while true; do
curl -s "http://kodi:[email protected]:8080/jsonrpc" -H 'Content-Type: application/json' --data "{\"jsonrpc\":\"2.0\",\"method\":\"Player.Open\",\"params\":{\"item\":{\"file\":\"$URI\"}}}"
sleep $[ ($RANDOM % 70 + 30) / 10.0 ]
curl -s "http://kodi:[email protected]:8080/jsonrpc" -H 'Content-Type: application/json' --data '{"jsonrpc":"2.0","method":"Player.Stop","params":{"playerid":1}}'
sleep 1
done
```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This happen to me very rarely, on my CoreELEC matrix nightly (ARM)
and only after play/stopped a lot of videos, after about 6 or 10 videos depends, sometimes this problem not happen and all works good
When this problem happen, can happen these behaviours:
After tried a lot of times i have managed to restrict the field on the problem:
kodi.old.log.txt
kodi_crashlog_20210704080408.log.txt (same log but with coreleec crash report)
on first log file, line 9150
Session::DisposeDecrypter()2021-07-04 08:02:05.088 T:5707 ERROR <general>: AddOnLog: inputstream.adaptive: Session::DisposeDecrypter(): ENTEREDis run and the code freeze inside this method, seem to always wait at cdm close session message,
then if cdm session close message:
you can see from the log that in this case Kodi is freezed 1 minute:
2021-07-04 08:03:05.484 T:5707 DEBUG <general>: AddOnLog: inputstream.adaptive: CDMMessage: 4 arrived!The text was updated successfully, but these errors were encountered: