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.

@kas1e

And that fix has worked fine? That's the one I was using before libcurl 7.85 (when that fix became part of the official source, although only when gethostbyname_r is not available in bsdsocket.library).

libcurl 7.68.0 came out in January 2020, but you'd sent me that hostip4.c file sometime in or before January 2016 when I used it for libcurl 7.46.0

@salass00

So there's definitely still a problem with gethostbyname_r then. I'll make sure to avoid it in the future.

@kas1e

https://forum.hyperion-entertainment.c ... 0fdb89d2063434923dd56b8a3

I found that thread but it's from November 2012, so probably before you had the hostip4.c fix (now part of amigaos.c and used when gethostbyname_r is unavailable).

Edit: So are you saying it was ok after the hostip4.c fix? Or you still had issues? I should have clarified that I only meant after modifying hostip4.c (back then).

@kas1e

I can't remember if it was MUI-OWB or Odyssey back then (2016). I think Odyssey.

Edit: You had issues? I vaguely remember a time from before/after there was a threaded resolver, but not issues with it. My memory could be wrong though! Maybe it wasn't using a threaded resolver and I only thought it was?

My changelog on OS4Depot for libcurl credits both kas1e & Joerg for the threaded resolver fix in my 7.46.0 port back in January 2016. My recollection is that kas1e credited Joerg when he sent it to me. I don't know how long he had it for. The Odyssey changelog mentions a threaded resolver back in 2010 (from OWB history it seems), but I don't know what implementation that would have been.

Before libcurl 7.85, I was using a patch for hostip4.c that kas1e sent me (although I thought he got it from Joerg?), that used the method salass00 describes in post #160.

Since 7.85 with Futaura's patches for AmiSSL v5 in the official repo, that patch is in amigaos.c, but with the difference that it will try to use gethostbyname_r if it's available. It should be easy to just bypass that check or return false.

@Chris

All I know that might help is to know that *if* it's a problem of using gethostbyname_r, that it wasn't defined in older SDKs so when NetSurf + libcurl was built years ago it won't use that function regardless of bsdsocket.library version.

I don't know if that's the cause of the issue though, but it also only relates to resolving hostnames, and should be unrelated to any SSL issues.

I suggest for people having problems connecting to anything including non-SSL sites, test trying their router config page via direct IP address.