![]() ![]() The key difference that I worked out was that the HTPC & laptop were both upgraded from Windows 7, while the NUCs were straight Windows 10 installs.Īfter mucking around with ShowKey.exe (program that shows what button presses are registered, available here: ), I found that none of the specialised MCE buttons (the green button, info, recorded TV, guide, live TV, DVD menu & the colored buttons) would generate an output, even after reassigning them via Advanced MCE Remote Mapper ( 164252 (thread)). The remotes worked on my existing HTPC & tested fine on my laptop, but wouldn't work on either of my NUCs, either through the built in eHome Infrared Transceiver, or via a USB one. ![]() I have a new NUC that didn't want to respond to a standard MCE remote (or a Harmony configured as an MCE remote). Thought this might be helpful if anyone is struggling with an MCE remote on a new install of Windows 10. I realize this is somewhat incomplete info, but I'd appreciate any help. What is a good way to find out why the below lines appear for some files but not others? Later on in the logs, I see what appears to be an effect of the above "Visible Behind" issue:ĭEBUG: CVideoPlayer::SetCaching - caching state 2ĭEBUG: CDVDClock::SetSpeedAdjust - adjusted:0.000000ĮRROR: CDVDVideoCodecAndroidMediaCodec::GetOutputPicture unknown index(-10000)ĮRROR: Previous line repeats 14353 times.Ĭompare that to the working output from the same point:ĭEBUG: CDVDVideoCodecAndroidMediaCodec:: width(512), height(384), stride(512), slice-height(384), color-format(259)ĭEBUG: CDVDVideoCodecAndroidMediaCodec:: crop-left(0), crop-top(0), crop-right(511), crop-bottom(383)ĭEBUG: CDVDVideoCodecAndroidMediaCodec:: Multi-Surface RenderingĭEBUG: CRenderManager::Configure - change configuration. ![]() This is a complex section but I never see the 'Got intent' log in debug so it doesn't seem to be triggered. The last section that seems to set this true is the onNewIntent section. ![]() In addition, that may not be the code where the above "Visible behind request" gets triggered since in both the visible and invisible play the log immediately prior is not a DEBUG level log. It appears to be caused by either resuming from a screensaver or on playback start. The latter seems to apply equally to both the video that works and the video that doesn't. The XBMC code that logs that message is in XBMCApp.cpp line 443. I don't yet have any samples of affected files that can be shared (part of the incomplete nature of this report.) Transcoding the video to the SAME CODEC with ffmpeg results in a playable file. Copying the video of affected files verbatim causes the problem to follow the video. This does not seem to be format or codec specific. On some videos that used to play fine, Kodi 18.2 will seem to play them, but no video appears.įor as-yet unknown reasons, in the debug log on affected videos I get:ĭEBUG: GOT ANNOUNCEMENT, type: 1, from xbmc, message OnPlay I have been unable to collect enough information for a proper bug report, but what I've found so far is interesting enough that I thought I'd see what everyone else thought. So if this "CWebServer: Stopped" is the reason why apps like Yatse wont work any longer, why is the WebServer stopping and why not restarting again? > In this situation I would assume that my boy turned on TV via traditional remote control and then started a movie also via CEC (without Yatse etc.). Out of nowhere, some services stopped suddenly (also WebServer). When I then just restart Kodi GUI (it is an option in Kodi 18.2 under CoreElec 9.0.2 on my Odroid C2), after restart it works again. However I still can use traditional remote control (CEC) and use Kodi. Sometimes, Yatse (my android remote control app) tells me that Kodi is offline (not reachable). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |