Should be self explanatory, PKC has very good documentation. Just pick Nexus.
I run both PKC and PlexMod. Highly recommend giving PKC it’s own SD card. It’s very tightly bound with Kodi and will modify the database. It’s also difficult to uninstall and even with following the uninstall directions closely, I wasn’t able to uninstall it cleanly without impacting other add-ons.
That said, in terms of playback, the only difference is PlexMod passes the web stream URLs from the Plex server onto the internal player. That’s it. PlexMod doesn’t have anything to do with setting color bits, or DV playback, nothing. It has no capability to do anything like that. All it does it pass the URL on for the internal player and logic to handle. If there is a playback difference, it’s within CoreElec and how SMB vs webstream content is handled.
That said, there is a buffer/cache setting difference between webstream content and SMB playback. By default kodi will buffer webstream content, but won’t do so on local playback. This setting is a Kodi setting:
Buffer Mode - This setting will force Kodi to use a cache for all video files, including local network, internet, and even the local hard drive. Default value is 0 and will only cache videos that use internet file paths/sources.
Well in theory it shouldn’t affect DV playback, but there are at least 3 or 4 people in this thread already, who get 12 bit via PM4K and proper 8 bit with PKC or smb. I doubt, that it’s a coincidence.
You might be onto something here. I don’t know if it translates to playing video, but in this post using captures of a RGB png from coreelec I have found non-negligible errors in RGB output. The output being impacted by the kodi GUI seems like a good theory.
There is no “in theory” here. I understand there are differences, but simply pointing the finger at PlexMod is unhelpful.
All PlexMod does is pass on the webstream URL to the internal player as repeated over and over. If there are differences in playback, that’s an underlying CE issue between how SMB and webstream’s are being handled.
Blaming the add-on for color bit selection when there isn’t a shred of code in PlexMod that’s related is inaccurate. And why would there be code? All it’s doing taking the item selected for playback, grabbing the URL from the plex server, and handing it off to the internal player. That’s it.
Look to the internal player if you want to troubleshoot and start posting debug logs. Maybe it’s a timing issue, a difference between smb/webstream handling who knows? I’ve already shown that buffering is handled differently between the two.
Also, CoreElec isn’t the only OS that PlexMod runs on. This isn’t an issue with the DV or HDR content on Shield Pro, Zidoo, LibreElec, etc… That alone should be an indicator that the issue is within CE, and has nothing to do with PlexMod.
Are we still doing this? Multiple people have asked you to post debug logs. But posting the same screenshots over and over on 2x different forums is unhelpful.
Again, all PlexMod does is passes the webstream URL to the internal player. It has nothing to do with LLDV, color bit handling… Period!
If there are differences, turn on debugging and start looking at the logs in CE. If you’re too lazy to do that, fine. But posting screenshots isn’t helpful. Yes, there is a difference. No it has nothing to do with PlexMod but likely in how smb/webstreams are treated by the internal player.
I tested both DV remuxes you listed, “Anna” and “MI: Dead Reckoning”. No color bit issues when played through PlexMod.
I’m not doubting your experience, and I understand what you’re seeing. But I want to reiterate that the problem is internal to CE. PlexMod gets the URL from your server, hands it off to the video player and that’s that.
Search “VideoPlayer::OpenFile:” in your logs. You will see that how Kodi handles webstream files is different vs local.
Would turn component logging (Video) and post another log if you want to dig in more. Pannal also posted a beta PM4K version today, and enabled SMB direct path substitutions. You could also use that and compare the output.
Tbh, imo if you can setup a plex server, you can setup an Apache httpd server to serve the files out as well. IMO http is the best local network protocol for passing video that I’ve tried (compared to SMB, NFS, WebDAV and even uPnP).
Other day I tried to watch Austin Powers and it looked horrid, all aliased. I thought the movie was actually interlaced and the interlacing algorithm was bad.
What is a simple way to test for TV-led, Profile 7, CMv4.0? Have read several mentions of the ‘Saving Private Ryan’ and intro scene with clouds and flickering. I also have the DV Full Enhancement Layer Control & DV Full Enhancement Layer Test clips… but don’t know what to look for.
Presence of the OSD seems to impact FEL playback on 21-nightlies.
Tested 5x films.
Blade Runner (HDR). Bringing up OSD no impact
Dune (MEL). Bringing up OSD no impact
Saving Private Ryan (FEL). Bringing up OSD no impact
Anna (FEL). Starts ok, but as soon as OSD shows up, stuttering and film slows down to a slide show
1917 (FEL). Unplayable
That’s precisely what my VC-1 pull request is doing. You can set software decoding for 24p content and hardware decoding for the rest (ie interlaced).
There’s some glitch with the hardware VC-1 decoder and if interlaced isn’t set the movie doesn’t play at the expected frame rate. The bug affects even progressive VC-1 encoded files. That’s why all VC-1 content is being subjected to forced deinterlacing if you set the VC-1 hardware decoder to being enabled. And indeed you end up losing a lot of resolution for progressive VC-1 files. For actual interlaced content the hardware VC-1 decoder works fine, and the box isn’t actually powerful enough to deal with software decoding both VC-1 and deinterlacing.
this is really a problem, it seems to me that vc1 worked more correctly on older versions of Corelec. By the way, in CE20.4 also faced a problem on some DVDs when the progressive format is packed in 576i 25 fps. CE does deinterlace. Before that, I tested it on older versions, I don’t remember which one it was, it was better. I would like the CE on the s922x to be a more versatile player, so that both the Dvd and BD remux c 1080i VC1 work adequately.
From what I gather. The playback issue of hardware decoded VC-1 in coreelec has been a long standing issue for some time now? I suspect prior versions had only used software decoding for that codec maybe? Anyways, hopefully that pull gets incorporated.
Care to share a sample of that DVD content? I only have 1080p and 1080i VC-1 content on my end. And didn’t even think DVDs were encoded in VC-1 in any point in their existence. As far as I know this impacts ONLY VC-1 hardware decoding and neither MPEG-2 (which I thought was the only codec DVDs used) nor H.264 hardware decoding is affected by this particular bug (not to mention those two already have selectable decoding options).
