[macOS, Qt4] No previews of the vids

[barracuda156]

Describe the bug
Previews of the vids are broken.

Possibly important context: current version of MPlayer in Macports is broken for PowerPC, and I have not yet reverted to a functional one. I expect previewing not to depend on a player, but if it is, then I will need to address that issue first.

To Reproduce
Might be technically difficult, but if one has PowerPC Mac, then just run:

sudo port install smtube

Expected behavior
It is expected to show previews normally.

Screenshots

Your Enviroment

• SMTube version: 21.10.0
• OS: 10.6

Additional context
PowerPC

[smplayer-dev]

That problem with the thumbnails happens if the ssl libraries are not found (smtube won't be able of loading https urls).
You should report the problem to the person who did that Macports package (it's not me).

[barracuda156]

@smplayer-dev Thank you for help, I will see how to fix SSL linking if it fails. OpenSSL as such works and passes all tests on macOS ppc.

(I am sorry to bother you with this, and helping with advice is more than enough. A port maintainer is not active for quite some time, and fixing PowerPC is kinda on me.)

[barracuda156]

For the player, I have added support for QMPlay2 today, and it works perfectly for playback. Only previews are left to fix.

[barracuda156]

Looks like it is not linked to OpenSSL for us, and that would explain why on 14.2 it works (there is a capable own SSL) but on 10.6 does not:

36-246% otool -L /Applications/MacPorts/smtube.app/Contents/MacOS/smtube 
/Applications/MacPorts/smtube.app/Contents/MacOS/smtube:
	/opt/local/libexec/qt4/Library/Frameworks/QtWebKit.framework/Versions/4/QtWebKit (compatibility version 4.9.0, current version 4.9.4)
	/opt/local/libexec/qt4/Library/Frameworks/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.7)
	/opt/local/libexec/qt4/Library/Frameworks/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.7)
	/opt/local/libexec/qt4/Library/Frameworks/QtNetwork.framework/Versions/4/QtNetwork (compatibility version 4.8.0, current version 4.8.7)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 117.0.0)

[barracuda156]

Is there a way to configure smtube to use a specific SSL lib? I cannot fix anything for SSL and cripto in the source beside of the following in one header:

#ifdef YT_OBSOLETE
	void errorOcurred(int error_number, QString error_str);
	void signatureNotFound(const QString & title);
	void noSslSupport();
#endif

[smplayer-dev]

There isn't SSL code in smtube. Qt loads and uses the SSL library. I don't know about Mac OS, but on Windows I have to install the libraries libssl-1_1.dll and libcrypto-1_1.dll.

[barracuda156]

@smplayer-dev Got it, thank you.

While macOS own SSL libs on systems where we use Qt4 are archaic, I think Qt4 in Macports is or at least should be using a modern OpenSSL (Macports-supplied), so it is not immediately clear what is going wrong, but this can be investigated.

I will build SMtube on Intel machine with old macOS to see if the problem is present there (that will also rule out any unrelated problems like an internet access setup). If it is, then Qt4 is the suspect.

[barracuda156]

A quick update, just for the record, the issue it not PowerPC-specific, I have the same behavior on 10.6.8 x86_64:

[barracuda156]

@kencu Ken, maybe you could take a look here? Since I have verified this is nothing specific to PPC of any sort or locally patched ports (my 10.6.8 x86_64 uses pre-built ports, Xcode 4.2 and no customization).

[barracuda156]

Ok, just to make sure, I built SMtube on Catalina with Qt4 and got the same issue:

[ghost]

Why don't you use Qt5?

[barracuda156]

Why don't you use Qt5?

@iahung2 Unfortunately, it is broken on PowerPC and early Intel.

(If you wonder why – because Qt upstream has broken the code to the extent of fixing it becoming non-trivial and enormous task. In particular, Carbon code was dumped from the start, and Cocoa was already broken in Qt4. To make things worse, support for Intel systems was removed quite early (AFAIK, 5.3 was the last version someone could build with substantial hacks on 10.6), then support for 32-bit was dropped, no one tested builds with GCC, so unsurprisingly even that has to be fixed, etc.)

Of course on Catalina is can be used and is used now, I just tested with Qt4 to ensure the issue is not caused by old macOS SDK or outdated system libs. It is not.

[kencu]

I looked into this issue a few years ago... MacPorts is building qt4 against a current version of OpenSSL, but I believe the code in qt4 is not using/calling the current SSL protocols.

I remember digging into the qt4 code and trying to find where the openssl calls in qt4 were being generated -- and finding them. But I didn't get to the point of patching qt4 to use them.

One very simple thing to have a quick try of is using squid to rewrite the SSL using it as a proxy server. I set that up manually, but then Jonathan wrote up a very nice package for it that is trivial to install. It can often be made to work with any software that can be tweaked to use a proxy server. You can get it here:

https://forums.macrumors.com/threads/fixing-https-issues-on-old-versions-of-os-x.2281326/

https://jonathanalland.com/downloads/legacy-mac-proxy.dmg

[barracuda156]

@kencu It would be of great help in fact to fix it, I think, not just for this specific port, but generally, since many ports depend on Qt4.

Maybe this fork will have fixes? https://github.com/fluxer/katie
UPD. Prior to fluxer/katie@fba2c21 which dropped SSL. But the code differs from Qt4 4.8.7, and is rather recent. Chances are it works.

UPD2. Specifically, at the time of fluxer/katie@a5df6c4 it was supposed to work with OpenSSL 1.1, when earlier OpenSSL has been dropped. This is 2021, much more recent than Debian patch from 2016 which we use in Macports.

[ghost]

@kencu It would be of great help in fact to fix it, I think, not just for this specific port, but generally, since many ports depend on Qt4.

Maybe this fork will have fixes? https://github.com/fluxer/katie UPD. Prior to fluxer/katie@fba2c21 which dropped SSL. But the code differs from Qt4 4.8.7, and is rather recent. Chances are it works.

UPD2. Specifically, at the time of fluxer/katie@a5df6c4 it was supposed to work with OpenSSL 1.1, when earlier OpenSSL has been dropped. This is 2021, much more recent than Debian patch from 2016 which we use in Macports.

See:

https://github.com/fluxer/katie/wiki/Unsupported-Operating-Systems

fluxer/katie#13

fluxer/katie#14

It seems Darwin is on the list of unsupported operating systems. Please correct me if I'm wrong.

Update: @barracuda156, you are on that repository, too: fluxer/katie#15. You should know the developer's attitude. Long story short, the only purpose of katie is to power his Katana DE. It's not Qt4, and it's not a general purpose GUI toolkit anymore.

[barracuda156]

@iahung2 I am not suggesting to submit anything to katie repo, I am suggesting it may be worth to borrow some improved code from there.

Obviously, I am not gonna backport anything blindly. I will review how much should be backported, if it is not something ridiculously huge, I will rebuild Qt4 with added patches, if that works, I will see if it resolves the problem we are facing. If that is also positive, then I submit a PR to have it fixed in Macports.
Whether Katie itself supports Darwin or not is irrelevant to the whole process.

[RJVB]

Looks like it is not linked to OpenSSL for us, and that would explain why on 14.2 it works (there is a capable own SSL) but on 10.6 does not:

36-246% otool -L /Applications/MacPorts/smtube.app/Contents/MacOS/smtube 
/Applications/MacPorts/smtube.app/Contents/MacOS/smtube:
	/opt/local/libexec/qt4/Library/Frameworks/QtWebKit.framework/Versions/4/QtWebKit (compatibility version 4.9.0, current version 4.9.4)
	/opt/local/libexec/qt4/Library/Frameworks/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.7)
	/opt/local/libexec/qt4/Library/Frameworks/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.7)
	/opt/local/libexec/qt4/Library/Frameworks/QtNetwork.framework/Versions/4/QtNetwork (compatibility version 4.8.0, current version 4.8.7)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 117.0.0)

This is nomal on all but the really old Darwin versions: it is not necessary for the dependent to link to libraries used only by a dependency like QtNetwork.

The MacPorts port:qt4-mac actually does link to OpenSSL rather than letting Qt load it at runtime. But it depends_lib on port:openssl which has been a shim for OpenSSL 3 for a while. Apparently QtNetwork builds and links against that version but I don't expect code originally written for OpenSSL 1.0 and then patched to work with OpenSSL 1.1 to function correctly with OpenSSL 3.x .

I can confirm that it still works just fine with OpenSSL 1.1.1w though.

[barracuda156]

I can confirm that it still works just fine with OpenSSL 1.1.1w though.

@RJVB Do you mean Qt4 generally or specifically previews in smtube when built with Qt4?

P. S. I guess our Qt4 should be reverted to use OpenSSL 1.1.

[RJVB]

Do you mean Qt4 generally or specifically previews in `smtube` when built with Qt4?

I mean generally, I don't have `smtube` installed. But if smtube uses the QSsl socket functions to connect to https servers this should work just like any other secure connection to a server using those classes. IMHO, if it doesn't work while other servers/services do (like the securesocketclient example) then the culprit is likely that OpenSSL 1.1 is not supported anymore by the server.

[barracuda156]

Oops, looks like smtube stopped working. With Tonvid.com I see this:

A client error occurred: Error calling GET https://www.googleapis.com/youtube/v3/videos?part=id%2Csnippet%2Cstatistics%2CcontentDetails&chart=mostPopular&maxResults=10&regionCode=TW&pageToken=&videoCategoryId=10&key=: (403) YouTube Data API v3 has not been used in project 861556708454 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/youtube.googleapis.com/overview?project=861556708454 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.

Own YT site does not even load.

Any alternative which is still alive?

[RJVB]

Any alternative which is still alive?

QMPlay2 uses `yt_dlp` behind the scenes, and that is being kept uptodate for now.

[barracuda156]

Any alternative which is still alive?
QMPlay2 uses yt_dlp behind the scenes, and that is being kept uptodate for now.

Unfortunately, it does not work directly from Qt4-based version of QMPlay2, not yet at least. I can only forward from smtube to QMPlay2, but not use its internal module for YT.

[RJVB]

The suggestion was more that maybe smtube could migrate to using yt_dlp too.

[barracuda156]

The suggestion was more that maybe smtube could migrate to using yt_dlp too.

It has that option (or at least its port does).

I could get YT back after adding an API key, but for some reason no FHD, despite preferences being set.

Do you think backporting support for modern YT from current QMPlay2 into earlier, Qt4-based, is reasonably doable? I can probably handle the code, but it’s a lot of work due to amount of changes over years.

[RJVB]

On Monday November 04 2024 06:52:30 Sergey Fedorov wrote: Do you think backporting support for modern YT from current QMPlay2 into earlier, Qt4-based, is reasonably doable?

Into Qt4-based QMPlay2? Probably but I'm not very familiar with how it works in detail. I know it uses yt_dlp to obtain just the URI for the video and the audio stream of choice - there's a rather "licked" way of determining the optimum quality combination. FFmpeg does the actual downloading. As long as that old QMplay2 version already handled YT more or less the same way the backporting could be as trivial as backporting Qt5 to Qt4 code...