[host505]

IIRC yatse has some actions pre-configured that you can set to a specific button.
If playerdebug is not one of these actions, I don't think you can do much about it.

[Tolriq]

Yatse can do 100% of possible Kodi commands and much more

http://yatse.tv/redmine/projects/yatse/w...omCommands

Just add a custom commands of type Built-In http://yatse.tv/redmine/projects/yatse/w...In-command with value Action(playerdebug). Then you may assign that to a remote button too.

Anyway for Yatse questions there's a tons of way to contact me to have answers and support.

[MidnightWatcher]

Hi Tolriq, thanks! I tried using Action(playerdebug) as the"Keyboard key or code" but nothing happens. Any ideas?

Edit: I've tried it as a custom built-in command also, but it isn't working.

[Tolriq]

Just tested it does work perfectly, but as said this is not the proper place to get support on something unrelated

[MidnightWatcher]

Got it working! Instead of editing the old custom command I had to create a new one.

[mthawk]

Hello.

I have 2 questions.

1. After update to new Kodi 17 Krypton i cannot access either codecinfo nor playerprocessinfo when audio is playing
I used this information before at fullscreen mode to get bitrate, bitdeepth channels count and other information for audiofiles (especially for online streams)

How to access this information with Kodi 17 ?

2. I use Kodi running on R PI2b and use my TV remote for controlling it.
Before i made customization to get CodecInfo window with remote key.
<keymap>
<global>
<keyboard>
<key id="254">codecinfo</key>
</keyboard>
</global>
</keymap>

I changed it now to
<keymap>
<global>
<keyboard>
<key id="254">playerprocessinfo</key>
</keyboard>
</global>
</keymap>

but thereis no effect. Still i see this ugly non-informative screen CodecInfo.

Please, help with your advises.

[host505]

My advice is to read back on this very thread.

[raspberry_pd]

Having CPU load on the same screen as codec info makes no sense. If someone gets to the stage of looking at CPU loads she/he should be aware of the type of content playing.

That's ridiculous. People may want to know, especially on dated hardware, whether their systems are capable of playing various types of video. One of the easiest ways to do that is to see the codec, renderer and CPU load in one shot. For example, the Raspberry Pi is the most popular platform for Kodi and it doesn't have hardare decoding support or x265. The devs have made adjustments to try and improve how the Pi plays x265 though, but current generation hardware may not ever play back very high bitrate/resolution. So people need to be able to see the codec being used whilst the CPU cores - all four of them probably - are being pegged in order to absolutely confirm this.

This part of Kodi is less "codec" and more "performance". It's like running the task manager on a desktop OS. When things get sluggish on a desktop, it's not unreasonable to want to see a realtime snapshot of performance-related information. The same applies for Kodi. Call it whatever ... "CodecInfo" or "ProcessInfo" or whatever it may be.

Someone coded this, Kodi has been popular *with* this feature. People have used it and nobody ever asked for it to be taken away. So it's only the core devs that appear to have created this problem when they were, presumably, overhauling the video playback code. Fair enough there are limited devs but isn't it part of the FLOSS concept that if people want to contribute, they are often going to want to contribute to parts of the code that they are interested in? If the core devs on a FLOSS project aren't diplomatic and don't manage their attitudes in such a way that attracts more developers, they're stabbing themselves in the foot.

There are a lot of people invested in Kodi from simple users to testers, to distribution developers and their testers and volunteers. That's too many people gifting their time for just a handful of core people to dominate decision making.

More democracy in FLOSS, less debatable, unacountable meritocracy!

[ivanmara]

When press "o" button now in v17 i cannot see current audio/video bitrate and other codec information. Also in default skin i cannot see info about current playing video: 1080, 720, SD ...etc ... It is very useful informatin for debug! ... Please return back this information as like 16.1!!!

[FernetMenta]

... It is very useful informatin for debug! ...

when did you submit your last patch based on your findings?

[ashlar]

So bug reports have to be filed only by people coding? FernetMenta has got some strange ideas on how this venture succeeded before he came on board...

Furthermore, a non native English speaker can easily confuse the meaning of debug. It's quite likely ivanmare meant system optimization by it. If I managed to understand, I guess it wasn't too hard for anybody.

[FernetMenta]

So bug reports have to be filed only by people coding? FernetMenta has got some strange ideas on how this venture succeeded before he came on board...

why don't you compare the versions of video player, now and the time before I came on board. I actuallly started coding and contributing to this project because video playback was all but good at that time. I was not able to watch a whole movie without multiple major a/v issues. what do you think is more important: improving things for the majority or providing some info for a few users who feel happier with some numbers they don't know how to interpret? anyway, there will always be users complaining ...

always glad to see how improvements are honored

[Drag0nFly]

So bug reports have to be filed only by people coding? FernetMenta has got some strange ideas on how this venture succeeded before he came on board...

what do you think is more important: improving things for the majority or providing some info for a few users who feel happier with some numbers they don't know how to interpret?

So bottom line, you are now calling every user who relied on this functionality mentally deficient. And in a very matter-of-factly way. The wording is also phrased as though in order for you to achieve core functionality in VideoPlayer, a harmless debug screen would have to be sacrificed.

Your above statement perfectly sums up your sentiments towards Kodi's userbase FernetMenta; and everyone who isn't (gasp!) writing actual code but contributing to the project in numerous other ways; and wishing nothing more than its success. It is getting to be quite interesting to see the lengths you are willing to go to defend what has to be considered perhaps the most counterproductive feature change this project has seen, considering the time and effort spent on addressing the fallout, getting themers to play catch-up in order to put back a lite-version of what was removed in the first place, and generally toxic discussions; be it with other developers or mere mortal users.

anyway, there will always be users complaining ...

Yes, there will. And frankly, constructive criticism is good for any project. The difference here is that most people on this forum who actually still bother to voice their opinion now do so at the risk of being banned, having their thread moderated - or downright deleted as has been the case for others in the past.

That hardly qualifies as an environment where differing points of views are encouraged, and respectfully discussed for the betterment of the project, as opposed to nonchalantly being dismissed while at the same time insulting the userbase.

always glad to see how improvements are honored

I doubt many here are questioning your ability to improve Kodi internals, be it improving the audio engine, sync issues, or more lately, the VideoPlayer core in order for it to be more coherent and better optimized. You've certainly received acknowledgements for those things in the past. However, removing functionality purely for the sake of one's own 'holier-than-thou' delusions can hardly be considered an improvement.

[Av3nged]

What FernetMenta is trying to argue and I fully agree with is that things like bitrate or codec should already be known so including that info would be redundant.

[furii]

However, removing functionality purely for the sake of one's own 'holier-than-thou' delusions can hardly be considered an improvement.

when the previous iteration came with performance cost, causing or exacerbating the issues the user is attempting to pin down, i'd hardly call its removal delusional.