BTW are you using a nightly or do those work in the latest Kodi 21 stable already?
Nightly but these options are existing since Kodi 21 and I am using them for a long time now.
Would love it if PM4K supported:
Label filters
Sort by âRandomlyâ
I find these two features helpful for browsing and choosing movies in Plex on ATV
I have been running PM4K over com build A11 since it released, and it run flawlessly all this months. This afternoon, I upgraded to v14. Since then, video goes faster than audio. There is a small latency in audio, about 1 second slower than video. Can this be due to dynamic latency introduced since A12?
I am using an UGOOS AM6B+, Sonos Arc soundbar, connected by HDMI to the TV, using ARC, and CoreELEC set to passthrough.
Downgraded to A11 and it was back to normal.
Is there any configuration that needs to be tuned from my side for these new releases on cpm or PM4K?
Thanks!
I have heard same a few people they experienced the same, including myself.
For some Alt seek on or off was the solution, for me in the long run nor on/off fixed it. I ended up reverting to the official CE build about 2 weeks ago, and havenât had the issue since doing that.
I am one of those. I also had trouble with audio after upgrading to A14. For me, enabling alt seek took care of it. It did not stop me from ârevertingâ to the official CE builds and those run without any problems
This is implemented in the beta.
Ok, clean profile - done - but back to CPM A14 / with CPM default skin
Now the issue i get is the âresume video partâ being broken
You resume at âxx:yyâ (at a certain timeline) - but when the video plays back you get almost 10-20 minutes ahead, at least (or more, itâs not consistent)
What was the fix for this, please?
Thanks & regards
The alternate seek fix. And you might have old AddonSettings still (the seek fixâs wait time might be too low)
When PM4K connected to an offline server a couple days ago, the â3 Dotsâ showed up, and I couldnât switch servers. Has it happened to anyone or just me?
Increased to 500ms - no issues now
It was 350ms before (when these issues started happening again)
Hi, can somebody please explain me path mapping feature or point me to some documentation? I use PM4K on Ugoos AM6B+ with Synology. What do I need to do, to use NFS or SMB instead of HTTP streaming? I tried to long press OK of my remote on my TV Shows icon in PM4K, selected Map option, it asked a Kodi directory, I selected randomly one, but nothing happens after. Can somebody please explain? Thank you.
Go to âFile managerâ in Kodi and âAdd sourceâ - either an NFS or SMB directory that youâre sharing with Synology - so you can point to that shared TV Shows folder when trying to map in PM4K.
If youâve set it up correctly, going to âSettings > Show Stream Infoâ while playing an episode will show âmapped (nfs)â or âmapped (smb)â instead of âhttpâ under the âModeâ details.
Thank you, I will try. Just one more clarification please: the NFS or SMB directory I will share must be just an empty shared directory or it should be really a shared folder where there are the contents (e.g. TV shows)?
The directory youâre adding in Kodi should be your actual shared directory with content, so you can point to the folder that has all of your TV shows when mapping them in PM4K.
Whatâs the advantage to not using the default http? Everything direct plays here instantly, default.
I got the inspiration from the video I saw posted in CE forum, and I remembered PM4K has the path mapping feature, that I never tried. Since the post promises quicker library scans, playback start, just more stable connection, I decided to give it a try. I had no issues with default HTTP streaming, since I have gigabit wired connection to my NAS and properly set cache and buffering settings, but after quick test I feel like when I use path mapped NFS, seeking in movies is faster. I think I will keep using NFS, but I need to do more tests. At first sight, it seems it is better for my setup.
I guess Iâd have to see results to bother. Somehow I doubt itâs any different. The video should have just shown a quick test of each.
Yes, then you had a previous beta installed that used 350 as a default value. This happens in beta ![]()
It tends to make a difference in high bitrate scenarios (peaks). Protocol overhead with NFS is the lowest. Iâve posted a short deep dive a couple of months ago.
Can you please link again the deep dive post? I could not found with search in this topic. Thank you.