I wouldn't have thought a newer version of NetSurf would have improved compatibility with YT.rexx. If I remember correctly, you recently started using the AutoPlay option in YT.rexx, which means all NetSurf has to do is give YT.rexx the URL, and the video starts playing with no further input necessary.

Also note that AutoPlay only works with links to a single YouTube video (i.e not from the search results page). It would save a bit of time if NetSurf had the ability to right-click and "Open link with".

@white

Glad to hear (read?) it.

@Deniil

Perhaps turning off hardware acceleration in Firefox will help.

@Hans

I've sent you an e-mail with my cmake toolchain file for cross-compiling. It's not perfect has helped me in the past.

@white

I don't think those WinUAE fixes have any relation to this specific issue.

Next time it happens, send me another GrimReaper crashlog and YT-Debug.log file in an e-mail. If I recall correctly before you edited the post, the crash was in the module dos.library.kmod. To me that indicates it's not actually curl crashing. I was thinking maybe it's memory corruption. The script shouldn't be behaving any differently.

If you can e-mail me 2 different YT-Debug.log files, one where it works fine, and one where the crash happens, I'll at least be able to tell you if there's some significant difference or not in the way YT.rexx is behaving.

Wow that's a lot of stuff. I only wanted 1 line from it, the curl line that crashes. Crash logs won't help because I don't have any build of curl with debug symbols.

Can you edit your posts and remove all that stuff? It's causing this page to not display correctly.

I've sent you an e-mail with something to try.

Your debug log file seems nearly complete but missing the part where it tries to play the video. It's interesting that it didn't just freeze and go no further at the last curl line.

Seeing as you're on WinUAE and I've had issues with curl on it before, can you try using RTL8029 PCI card emulation instead of A2065, and use rtl8029.device that comes with OS4.1, and reduce your memory a bit. Try 512MB of RAM and 128MB of VRAM.

I notice other issues with not being able to parse the .js file. So, even if everything else was working, that particular video wouldn't have played. I'll look into it.

Edit: Fixed .js parsing, but I'll do some more testing before uploading an update.

Edit 2: I just noticed your crash log says it was in dos.library.kmod. That doesn't seem right. As above, try reducing your WinUAE Z3 memory to 512MB and VRAM to 128MB and see what happens.

Yeah it looks like some crash in curl. You could look through the YT-Debug.log file and try to re-run curl with most of the same arguments, but maybe take the s out of -Lkso. Dwarf stuff I've only seen when kas1e informed me about some problems he had when mixing libraries built with different gcc versions (but that issue was sorted out for him). curl itself is a statically linked binary that's tested before being put on OS4Depot, so it should be fine.

I did notice a double-slash in that path name, but it's probably just a quirk of gdb.

I have the same question as broadblues. Did the GrimReaper window open first? If you were typing away at the time, it may have only briefly flashed on the screen. If so, looking through the YT-Debug.log file to see what the full command line arguments were for curl, will help.

When you say "video search function", I'm not 100% sure what you mean. YT.rexx will detect a non-YouTube site and scan the webpage for links to YouTube videos. When it does that it will be running curl many times (not simultaneously though). Perhaps there's some issue when it's ran over and over again in quick succession. Out of curiosity, how many megabytes of memory are you using in WinUAE? Are you using the 64bit or 32bit version of WinUAE?

Hi,

It's better but not 100% correct.

PathFP="APPDIR:Amiga:Utilities/FFmpeg/Generic/ffplay.xdelta3"

.xdelta3 is not an executable file. After extracting ffmpeg.lha, you need to run the "Unpack" script which creates the remaining binaries from the xdelta3 files. It works similar to spatch or gpatch which you might be more familiar with. In summary, extract ffmpeg.lha to RAM:, then in shell type "cd ram:ffmpeg" then "unpack" and you'll have the proper ffplay binary.

Also, if you're using a non-APPDIR path, get rid of APPDIR: from the start, so the line looks like:

PathFP="Amiga:Utilities/FFmpeg/Generic/ffplay"

All that being said, ffplay is/was only used to play live streams, and YouTube has deprecated HLS streams and they don't work properly anymore. So, there's no real need to worry about fixing that path or installing ffplay anyway.

Edit (2nd March): HLS streams over SSL/TLS has been fixed in the ffmpeg git repo. A fix from December '17 hasn't made its way into any official release yet.

@white

A lot of your arguments have a space after the first "-" that shouldn't be there. For example, you have "- vo sdl", and "- quiet", and "- loglevel". MPlayer will be treating the "-" on its own as a special filename and redirect input from STDIN. You need to remove those erroneous spaces.

"-quiet -really-quiet -vo sdl" will work fine.

You've got a few "- " elsewhere that should be removed.

The [CLI 5] thing is because you used C:run instead of Rx, but I see you've solved that now.

Also your APPDIR paths are messed up, you have too many spaces on those lines as well.

PathMP = "APPDIR: Work: MickjT-Mplayer / mplayer-nonaltivec" / * Full path to MPlayer executable * /
PathFP = "APPDIR: ffplay" / * Full path to FFplay executable * /

That's not right, it should be:

PathMP = "Work:MickjT-Mplayer/mplayer-nonaltivec" / * Full path to MPlayer executable * /
PathFP = "APPDIR:ffplay" / * Full path to FFplay executable * /

More spam: http://os4depot.net/index.php?functio ... le=game/board/54321.lha#1

@white

You don't need to set AutoPlay="1" in the script. Just having autoplay as a parameter after "silent" in the IBrowse menu item settings is fine, unless you wanted it on by default.

@white

I've already replied to it :) The instructions I gave you in the e-mail are only useful if you're using the AutoPlay option. I'll repeat it here though for anyone reading this.

You only need to follow the instructions in the guide on adding the "Open with YT.rexx" menu option, but add "autoplay" to the list of parameters, and maybe rename the menu item to "Play with YT.rexx" instead so you can remember what it will do, then adjust the TagOrder list at the top of the script to put your preferred resolution at the beginning of the list (see YT.guide regarding that setting).

@Severin

The reason there's been no update is because everything works here and no-one has reported any bugs. I can only fix things I know about :) I've sent you an e-mail.

Also, you need to be using 1.5. If you're still using 1.4, then not much will work with default settings.


@white

If the links don't work in IBrowse, but you can Copy them to clipboard and they work in Odyssey, then the issue is SSL with IBrowse. You can still use the AutoPlay option that YT.rexx has and make a "Play with YT.rexx" menu option. Check YT.guide for instructions on setting that up.


Edit: Remove unnecessary snarkiness :)

@ChrisH

Yes it should have everything from his builds too. The reason I drew your attention post #25 was that I originally was just going to replace afxgroup's version, but by request, I didn't :) So yeah, just "more up to date" is the primary goal.

@ChrisH

That's pretty much it, and other minor things noted in the changelog. Also see #25.

Sorry about 1.0 then too :) .. but I don't think I need to retroactively call that one something different in the changelog, otherwise I'd then have to bump the revision even further, not to mention cause confusion referring to 1.0.1 as 1.2, and 1.0 as 1.1.

It's been pointed out to me that 1.0.1 is not an Amiga version number. The whole reason I called the first release "1.0" was to have a compliant version string. It slipped my mind. I'll retroactively call 1.0.1, 1.1, and the next version can be 1.2. Sorry about that everyone :)

@LiveForIt

Thanks for the explanation. That explains the even worse distortion if I disable the JIT function entirely. A hack to decrease the volume in software would work, but it seems a little crude to do that. I'm clueless about how the AHI & JIT code works, so I'm not the right person to modify that code directly.

@TSK

You can use the 9 and 0 keys to change the volume level, if you have input.conf in the conf directory.

I'm assuming you mean the audio is clipping, and that's what you mean by distorted.

I played the 640x360 MP4 video and hear audio clipping. It seems like it happens only when using FLOAT_BE output in AHI. Changing the audio levels in AHI or MPlayer itself doesn't have any effect. I will need to investigate. LiveForIt-MPlayer doesn't natively play this output to AHI, but converts it to a different format while playing back. The ahi_dev2 I'm using is from Kjetil but it's still experimental.

Edit: Can you try with -softvol -volume 50 (and other volume levels with softvol enabled) and tell me if that "fixes" the issue?

@TSK

Any example videos I can try? Do you use playlists at all?

I know of 2 types of distortion issues. One is when switching between audio formats from FLOAT_BE to something else if you're using a playlist or specifying 2 or more files on the command line. The other is just when the audio plays too loud. If it's mp3 audio, try -ac ffmp3float.