It compiles if you use

ppc-amigaos-g++ -o atomic atomic.cpp -std=c++20 -athread=native -latomic

or

ppc-amigaos-gcc -o atomic atomic.cpp -std=c++20 -athread=native -latomic -lstdc++

There were 2 issues. One specific to the IOS player client, and the other affecting all player clients.

@skynet

Message me your email address.

@K-L

This is something that needs to be sorted out in YT.rexx. Send me a private message with your email address. (Edit: n/m I have it and sent you an email)

It was fixed in YT.rexx 3.3 but maybe there's been a recent change that requires another fix.

Edit: The .m3u8 changed slightly, but I only notice it with the IOS client. I sent you something to test.

I noticed the download link for the OS4.x version is broken.

https://www.ibrowse-dev.net/download.php

On a fresh install of OS4.1 FE + Updates, AmiUpdate fails to download this so I went to the website manually to discover the link is broken.

@smarkusg

The latest branch I can see is here: https://github.com/khval/e-uae-1-0-0/tree/uae-1-1-2

Perhaps it's something in APPDIR: pointing to ADH0:

You can try a different USB port for the keyboard.

@TheMagicSN

If it was using threads.library instead of pthreads.library, and you were using libpthread.a (rather than .so), then it was the wrong libpthread.a too.

Both the .a and .so will use pthreads.library.

The .so is in SOBJS: and comes with OS4.1 (a symlink is made in SDK:local/newlib/lib during the SDK installation). The .a is installed by the SDK installer (from pthreads-53.12.lha).

My guess is that you'd overwritten the .a with the old one on OS4Depot (and if you were using -use-dynld and the .so symlink wasn't there, it would use the .a). Follow my instructions a few posts above and remember to delete the old pthread.h header file (if you have one in clib2/include or newlib/include), because otherwise it won't use the newer one in common/include.

@TheMagicSN

If you're using libpthread.so then I would have thought you're already using pthreads.library because there is no .so in that archive on OS4Depot (perhaps -lpthread is not finding a .so if the symlink is missing, and using the .a).

But in the case that it's not using pthreads.library, make sure your clib2/newlib libpthread.a hasn't been overwritten by the one on OS4Depot.

If it has been, this is what to do.

Inside SDK_54.16.lha is pthreads-53.12.lha. Extract that to your SDK directory, overwriting what you have. This doesn't contain libpthread.so but a symlink will be created later.

You also need to delete pthread.h from SDK:local/newlib/include and SDK:local/clib2/include. The newer header is in SDK:local/common/include

If you already have a SDK:local/newlib/lib/libpthread.so, it might be the wrong one. Create a soft symlink so SDK:local/newlib/lib/libpthread.so points to SOBJS:libpthread.so. This is how the SDK installer does it.

Check your SOBJS:libpthread.so is the right one. Mine is 162435 bytes with a date of 6th Jan 21.

Glad it worked :)

Perhaps it's a similar issue to this?

https://www.amigans.net/modules/newbb/ ... id=151175#forumpost151175

@all

It was a small bug. If you're using WEBSAFARI, it works best as a command line argument rather than in the .cfg for now. Fixed for the next version. Didn't affect most videos, just ones set to not allow embedding.

@Maijestro

If you see a big VEVO logo in the bottom left corner of the thumbnail, then it's a VEVO video. Many music videos are.

@Mozzerfan

Those links are working here. I'll send you a private message.

@K-L

Are you using it via shell? After seeing the first 360p option, press enter go to the next section which should be the HLS streams.

Mozzerfan probably wants music videos to work though, so I'm interested in which ones didn't work.

@Mozzerfan

I tried 3 different VEVO music videos with WEBSAFARI without a problem. Can you be more specific?

The IOS client returns HLS streams that have the video and audio split. That is supported only if using the Play Video or autoplay options, but doesn't work in Emotion.

MEDIACONNECT is no longer working, but WEBSAFARI is another alternative that also returns combined video+audio HLS streams and is compatible with Emotion. Edit TagOrder to remove "18" or move it to the end.

For non-HLS, ANDROID is working with a 30 second expiry, and WEBEMBEDDED should work again on the next release, but not right now. I'm looking into any other options.

Edit: IOS DUALPLAY is another non-HLS option if you're using mplayer. There are DashTagVid and DashTagAud options in the .cfg. The default is 360p if those settings are missing.

@Tuvok

Check libs:AmiSSL/ and see if you have amissl_v111m.library. If not, download AmiSSL 4.12 from https://github.com/jens-maus/amissl/releases/tag/4.12

Don't install it (I assume you have the latest AmiSSL v5 installed already). Just copy *only* that 1 file over into libs:AmiSSL/. You might need to reboot. Then try again.

I don't know if this is still required, but it used to be, to get https links working.

@Chris

Isn't the threaded resolver working ok now (with _r disabled)? Did Netsurf's libcurl have the threaded resolver enabled previously, years ago (with different patches) ?

I thought netsurf_os4_amissl_no_r.lha had the threaded resolver enabled but just not using _r. I didn't personally test it though.

@redfox



Is that working without problems for you?

If that one has the threaded resolver enabled (but not using _r), then I would expect a version that uses AmiSSL should work fine too.

@Raziel

I think some people might be conflating 2 different issues. The gethostbyname_r issue only relates to libcurl resolving hostnames (Chris's latest Netsurf build is now linked against a libcurl that has that function disabled). Although libcurl uses either OpenSSL/AmiSSL for fetching SSL content, any SSL issue is unrelated to the hostname resolving issue. gethostbyname_r is not present in the OpenSSL/AmiSSL source.

The reason your configure script doesn't find gethostbyname_r is probably because you're using an old SDK. That function wasn't present in the included newlib library/headers until SDK 53.34, and not in the included Roadshow headers until SDK 54.16.