3D Support builds for Raspberry Pi

Quote from vobs

But wait wait wait!!! I Think I found it: Just went through all the projector settings again and switched "HDMI LINK" ON. And boom! Not one single glitch since then (the movie has been playing for 10 minutes now - fingers crossed...). Why this?

I'm afraid this still doesn't make any sense. "HDMI LINK" is CEC. No obvious reason why it would affect the glitches.

Quote from ht2tweak

But, with last LE 3D build and CE22, even if using Files view, as soon as I choose ISO, no chooser, rather plays main title directly:

Quote

Root cause

His library holds the movie's file path as the playlist, not the ISO. CVideoDatabase builds every list item with

Code

item->SetDynPath(std::move(movie.m_strFileNameAndPath));   // VideoDatabase.cpp:8117

so the item already carries bluray://…/3-D Rarities (2015).3D.iso//BDMV/PLAYLIST/01001.mpls before he presses Enter. The new log shows exactly that:

Code

15:49:04.593  CInputManager::HandleKey: enter pressed, window 10025, action is Select
15:49:04.593  OnPlayMedia bluray://udf:///storage/Videos1/Movies3D/3-D Rarities (2015).3D/
                          3-D Rarities (2015).3D.iso//BDMV/PLAYLIST/01001.mpls
15:49:04.596  CPlayerSelectionRule::GetPlayers: considering rule: discimage

Note discimage is only considered, never matched — because the path is a bluray:// playlist, not an ISO. Compare the Spider-Man log, where the same rule reported matches rule: discimage.

From there, GetMenuDecisions gives NO_ACTION under Automatic menu selection: isBluray is false (dynpath isn't a disc image), isBlurayPath is true, and with BD_PLAYBACK_AUTO neither forceSelectionAtStart nor useDiscMenuSetting nor mainTitle is set, so every branch falls through. It plays 01001.mpls directly. AUTO is documented as "Only use simple menu if playlist not known" — the playlist is known, so it doesn't ask. Same for both volumes.

Why "play from Files" changed nothing: the dynpath comes from the database row, not from how he navigated to it. Window 10025 serves both views, and a Files item matched to a library entry gets the same dynpath. My suggestion was based on the assumption that Files view would give a raw ISO path — that was wrong, and I should have checked SetDynPath before offering it as a quick test.

Why IMAX / Best of 3D still work: those live under /storage/Videos2/Various/, and the earlier log shows them opening as raw .iso paths — not library items with a resolved playlist. So isBluray is true for them and the chooser runs.

How the path got stored

VideoInfoScanner.cpp:2140 — at scan time, when a playlist is known for a disc image, the scanner rewrites the item's path to the playlist:

Code

if (playlist > -1 && (IsBlurayDiscImage(path) || IsBDFile(path) || …))
{
  path = URIUtils::GetBlurayPlaylistPath(path, playlist);
  pItem->SetDynPath(path);
}

So any disc scanned into the library with a resolved playlist loses the chooser under AUTO from then on. That's the behaviour change he noticed, and it's a consequence of the playlist-resolution work rather than of the menu code.

What he can do today

• Set disc playback to Simple menu — forceSelectionAtStart && isBlurayPath && atStart then returns SHOW_SIMPLE_MENU, so the chooser comes back for library items too.
• Or Show Blu-ray menu, which he's already found works.

The decision for you

This is a design question, not a defect: under AUTO, a library item with a known playlist currently has no route to the disc menu at all — not via a chooser, and (as he notes) not from the OSD either. Options as I see them:

1. Let AUTO return SHOW_SIMPLE_MENU for isBlurayPath at start when HasMenuSupport() — restores his chooser, at the cost of a dialog on every library play of a menu-capable disc.
2. Leave AUTO alone and keep the OSD "DVD Menu" action available whenever the disc supports menus — closer to what he expected, and no extra dialog.
3. Do nothing: AUTO behaving as documented, and he uses Simple menu.

I'd lean to (2) — it addresses the actual complaint without adding a prompt to every play — but it's your call, and I'll implement whichever you pick.

Display More

So the important point is whether it's been scanned to library. library items line direct to feature, not menu.
I'll probably go with (2) so you get back the option of playing the menu.

Quote from vobs

Fully agree - that's why I haven't tried it any sooner. If I turn "HDMI LINK" off, the glitches come back immediately. Turn it on again and they disappear for good.

For interest, what happens with "HDMI LINK" on, but CEC settings disabled on Pi.

That should narrow down if its purely enabling "HDMI LINK", or if it's something it interprets from the CEC data that makes it choose to do the glitches.
Also does the projector have any sort of firmware update mechanism? It could be a bug they've fixed.

Quote from vobs

Some feedback from playing around: I tested a 3D file in 4K FSBS format (3840 x 2160), which is used for VR. Anyway: The Zidoo Z9X Pro appears to recognise, downsample and send it as 3D Framepacking, which is quite impressive. On the Pi 5, it is just sent as a standard SBS image which has to be manually switched to 3D using the projector's remote control. I guess this results in more resolution loss than with the Zidoo processing. However, to be fair, with the highest 4K FSBS resolution we sometimes see (7680 x 2160) the RTD1619BPD based Zidoo completely refuses to play.

That should be supported as frame-packed. Post a debug log so I can see what's going on.

edit: do you have a whitelist set up? I think if you do (and it includes [email protected]/1920x1080@24) then you'd get the FP output. I'll look into making that happen without a whitelist.

Quote from vobs

Awesome, thanks for the tip! I hadn't set up a whitelist. I have one now and it's working By the way, will we have to create a new image and set everything up from scratch when you release a new version? Or will it appear in the LibreELEC update process?

If you download the latest version (from first post) and put into /storage/.update and reboot it will update in place. No reinstall needed.