A question for @nico1080 …
For the calc_progress_pvr() the added functionality is to correct the progress value according to pvr offset. PVR offset is used as program could be early/late so recording need to be longer
Are the PVR start and end offsets constants (for a given PVR setup), or are they something that can actually vary per recording? I ask since, years ago when I had a TiVo, I think one could configure distinct start and end offsets specific to every series recording (Season Pass).
My PVR backend (TVheadend) allow me to make rules based on channel number, time, name of program etc to decide pvr offsets value (eg: 2min for channel that respect their scheduling and 10min for channel that don’t)
I could also manually specify different value for any recording/ series-recording/auto-recording etc.
However I created a rule that specify 10mm start/stop offset for all recordings. So in my case constant offset will always work.
I mapped buttons on my kodi remote to make +/-30sec and +/- 10min steps in my video. So with a few button pushes I am at the beginning of my program.
To my knowledge their is no way of retreiving actual offsets used by the PVR (no info label) I am not sure that kodi knows it (it is a PVR backend setting, not a kodi setting) and even if it does, it would depend of the PVR backend software, and PVR plugin in kodi.
I also tried theshare screen elements feature it work good with the progress bar, I will continue upgrading my configuration thanks 
@bossanova808
I guess you just have to tinker with it 
On my side I am looking into external monitor targeted for laptop they usually are 12/15", 1080p/1440p with IPS panel have hdmi and usb-c interface, some are touch screen and cost around 100/150$.
example 13.3" ips external monitor
I guess I will continue making layouts for my 640x480 6" lcd display (Draft of it is already on my git hub fork of @mblovell repo) , scale it for my 1440p desktop monitor and check system load with these high resolutions to see if an RPI3 can handle it.
Github recently added Discussions for projects, separate from but similar to Issues. If you have a github account and want to suggest some concrete improvement for kodi_panel, you can give
https://github.com/mattblovell/kodi_panel/discussions
a try as an alternative.
Naturally, you can keep posting here. This seems a better forum for people trying out different displays or new use models.
I’ve updated kodi_panel’s contributors.rst file to list both @noggin and @nico1080, for all the suggestions and code changes above.
New version is up on github…
Changed how “special treatment” for the fields array of all layouts is implemented. Responding to Ideas #16 and #20, two lookup tables of functions now exist in kodi_panel_display.py. These are
ELEMENT_CB: dictionary specifying callback functions that are free to draw on the image or invoke draw functions, as well as perform any desired string manipulation.
STRING_CB: dictionary specifying callback functions that are just expected to perform InfoLabel string manipulation.
The scripts that end-users invoke (e.g., kodi_panel_fb.py or kodi_panel_ili9341,py) are free to manipulate these two lookup tables prior to invoking kodi_panel’s main update loop. Existing entries can be changed to point to new functions, new entries can be added, and existing entries can be deleted. Some care is needed if referring to global variables within the kodi_panel_display namespace, but it should now be possible to customize lots of functionality without needing to edit kodi_panel_display.py itself (provided you’re willing to write some Python).
The string callback functions can also be referenced by format_str for fields (Idea #17). That is, one can now specify format strings using both Kodi InfoLabels and any of the named string callback functions for substitution.
Also added the ability to have the idle status screen always shown (Idea #15). The relevant TOML variable is ENABLE_IDLE_STATUS. All example setup files have been updated.
The video mode selection heuristic has now been moved to a standalone function. (Look for video_select_default() in the latest code.) The function is passed a dictionary with all of the video InfoLabels retrieved from Kodi, and must return the desired layout to use via the VDisplay enum class. The heuristic function is invoked from a “hook” variable.
An invoking script (i.e., the end-user’s version of kodi_panel_fb.py) can use that “hook” to make a different function responsible for the heuristic. So, you should be able to use any criteria desired (so long as it’s based upon the InfoLabels) for video layout selection.
I don’t know if there’s any demand for it, but I mirrored all of this functionality for the audio-side of things as well. The selection function is empty by default. It gets passed all of the audio InfoLabels that have been retrieved and must return an ADisplay enum.
Recall that recent versions of kodi_panel_display.py also permit the setup.toml file to augment the JSON-RPC query for audio, video, and status screens.
Cheers,
Matt
I took advantage of the display_if functionality that @nico1080 suggested, and added a new line-drawing callback, to arrive at the alternative layout below.
The changes are available in kodi_panel v1.34. As I remark in those release notes, I can’t decide if things are too cramped or not; having the artwork be as large as possible is nice though.
For anyone that cares - using old tablets (e.g. with Ubuntu Touch) - was a bit of a bust for this. Couldn’t get a working Python situation going on on any of them.
So I am back to buying a Pi + screen I think. Which doesn’t worry me but would have been nice to re-purpose old hardware…
I always struggled to do that.
I currently use an old 6.4" LCD with VGA connection, the viewing angle are terribles (20° at best)
I actually spent 10min trying to figure out why background color was not working until I realized that I needed to be in front of the screen 
Anyway with @mblovell we have been very busy on github discussion and he implemented a lot of functionalities.
I have also created a fork to show my config.
I have been using my old LCD hooked up an RPI 3 B+ running hyperion (ambilight clone)to test kodi panel and see if there was somme issue → after a week everything work fine, I never add any freezing or crash.
Kodi panel allow very easy and advanced configuration.
I added some specials functions, like displaying the logo of my video/audio codec (always nicer than just plain text)
All this change are documented in my fork, I tried to do a 1comit per item
Next step for me is to scale my config to 1440p to see if my rpi can handle high resolution without issue (my LCD has only 640x480 resolution)
I also took a few pictures to show how it work (still need some work, the “display optimization” will be done once I get a decent LCD)
My LCD showing my live TV layout next to my old HD44780 (that will be replaced by kodi panel)
The movie layout:
Tv show layout:
default video layout
PVR layout:
Live TV layout:
Music layout
And finally slideshow layout (same as @mblovell defaut layout I did not work on it)
Edit, sorry for the multiple post, but I am/was limited by the max number of picture/post
EDIT #2 from 2021-05-02:
I tested with higher resolution.
I was unable to output 2560x1440 on my RPI 3B+, I tried various framerate, but I kept having “no signal” or “unsupported signal” on my monitor.
This issue is not related to kodi panel but only raspberry PI OS.
Anyway, I tested 1920x1080p by scaling up my layout (basically, multiplying by ~x2.2 all the pixel/size values)
I had no issue regarding power usage (around 20% CPU load for kodi panel processus)
Only issue is that artwork get limited to the size of the thumb retrieved by kodi (no upscaling) so with high DPI display the artwork tend to be limited
Upsizing would need to use resize() rather than the current thumbnail() code:
Back in the commit history, kodi_display_panel.py originally used resize(), but care was needed to ensure that the existing aspect ratio was maintained. The thumbnail() function takes care of that automatically, but only wants to go one direction – smaller.
Enlargement of retrieved artwork should now be possible with kodi_panel v1.41. The upsizing occurs only if the enlarge flag is set within the artwork’s associated dictionary within the layout.
Sorry all - been a bit busy with other stuff - will have a read through this thread. Looks like you’ve mad huge improvements! Can’t wait to give the code a go!
I managed to get a Pi 3B or lower to output HDMI UHD 3840x2160p at 24 and 25Hz, and to feed an eDP iPad retina display 2048x1536 at 60Hz via an HDMI->Displayport adaptor. All of them took quite a lot of work in the custom HDMI timings in config.txt (and that may require you to use the legacy graphics driver rather than the new one - I can’t remember)
I finally got a decent LCD to use with Kodi panel
It is a zeulap 15.6" lcd with IPS panel. Viewing angle are very good. It as USB-c and hdmi connection (I use only hdmi)
I just scaled my existing layout to 1080p. 15.6" is maybe too big. I believe 10-12" should be the correct size.
I need to spend some time to work on my final layout. I will post more pictures then.
I also created a 3d printed stand for the screen, files can be found on my Thingiverse: https://www.thingiverse.com/thing:4800202
I also writed a light description on my github fork:
where is 16 bit support for the ili9341 fb ?
all luma examples work ,even xfce4 on the tft works
but can’t get any picture from kodi_panel
only get to 16bit not supported error
so i wonder what i dont see
ah found it somehow
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.
About | FAQ | Terms of Service | Privacy Policy | Legal Notice
