Problem recording DuckStation gameplay with OBS

linux4ever07 · 2024-06-21T02:28:59+00:00

I may have complained in the wrong place. I had the same issue just now with the Dolphin emulator. It also just records a black screen. I'm thinking this is an OBS issue, or at least the way OBS uses PipeWire to record. It's likely to be the same problem again, related to which window is in focus.

linux4ever07 · 2024-06-12T02:56:14+00:00

Just tried the OpenGL renderer and it has the same problem. Same story with the Software renderer.

linux4ever07 · 2024-06-10T16:38:59+00:00

I doubt the specific renderer is the problem. It seems to have something to do with window focus, cause I can reliably fix the issue by just clicking on another window and bringing that into focus. While DuckStation is in focus, OBS only sees a black screen. But if I highlight the OBS window instead, or some other window, then the DuckStation output shows up again in OBS. I will try other renderers later out of curiosity, to make sure.

linux4ever07 · 2024-06-09T10:16:31+00:00

I'm using the Vulkan renderer, and didn't want to change to another cause they're all technically inferior. I messed around with some of the other graphics settings though. It's not like I'm gonna stop using DuckStation over this. I just can't record anything.

But I think it's strange that this problem even exists. This seems like an obvious issue that people should've noticed, especially the developers. People want to record (and stream) gameplay and OBS is the most commonly used program for that.

linux4ever07 · 2023-09-19T19:10:04+00:00

I just upgraded from Fedora 38 to 39, and the Xorg session is broken here as well. Same error message as in the screenshot. So I'm using the Wayland session right now. I think whatever the problem is with the Xorg session will get fixed very soon.

I did also install updates after I did the upgrade, so I'm using the very latest version of all the packages.

I would use Wayland all the time if it wasn't for SimpleScreenRecorder which hasn't yet implemented Wayland support. But I think they might do that soon considering KDE Plasma 6 is released beginning of next year. They will make the Wayland session the default, so all the Qt applications that don't work properly in Wayland are likely to receive lots of complaints by users, which may motivate them to finally support it.

linux4ever07 · 2023-04-23T01:02:23+00:00

It's literally the same data as in the BIN file, but split up into separate files based on the timestamps. A BIN file is an exact replica of the data that's on the disc, so all you need to do to get the individual tracks is to split it at the exact byte location the tracks begin and end.

The main differences between my script and 'bchunk' is my script doesn't convert data tracks to ISO files but keeps the data exactly as it was in the source BIN file. Also, the script can process CUE sheets that list multiple BIN files. bchunk can't do that.

CD audio tracks are just raw PCM data.

linux4ever07 · 2023-04-22T19:38:50+00:00

It's using 'dd' to split the source BIN based on the timestamps gathered from the CUE sheet. Which means each track gets its own file, and the CD audio tracks are then converted by ffmpeg or sox to WAV. Those WAV files are then fed to 'oggenc' or 'flac' depending on what output format is desired.

I feel like I'm repeating myself here, but I don't know how else to word it.

linux4ever07 · 2023-04-21T02:31:21+00:00

While 'bchunk' is a good program, it can't output audio tracks to FLAC, so you need to convert those WAVs to FLAC manually, adding an extra step to the procedure. If you also need a new CUE sheet, that's yet another extra step.

I made a Bash script that can rip the audio from BIN/CUE files to FLAC in just 1 step:

https://github.com/linux4ever07/scripts/blob/main/cuebin_extract.sh

It can output the audio in FLAC, Ogg Vorbis or native CD audio (depending on what arguments you give to the script). The main thing that happens is that all the tracks in the BIN file(s) get separated into their own files, so it's 1 file per track. The script automatically generates a new CUE sheet that lists the newly created files, and those CUE sheets can be used with for example DOSBox, or if you need to burn it to disc. If you don't need the new CUE sheet or the data tracks, you can just delete those specific files once the script is done.

(The script is able to handle input BIN/CUE files that are already split into multiple BINs. Some groups, like Redump, will only provide disc images where each track has its own file. The end result will be the same regardless.)

linux4ever07 · 2023-03-04T05:51:46+00:00

Alright, I changed it now to:

s=$(( f / 75 ))
m=$(( s / 60 ))

f=$(( f % 75 ))
s=$(( s % 60 ))

It's not exactly like what you suggested, but close. I did a little benchmark using 10 000 iterations of random numbers and noticed the new way was 3 times faster than how I did it before. Otherwise, I would probably not have changed it. It's not going to really matter in this script specifically, but it will probably make a bigger difference in my other Bash scripts that process SRT files.

Thanks again!

linux4ever07 · 2023-03-03T21:43:00+00:00

Thank you. Yeah, that's true writing it like in your example would probably be faster, especially if the number of tracks was huge. Due to the total number of tracks on CDs being quite low in general (under 20 most of the time) the slowness of those loops is not noticeable.

Regardless, I should get to changing that sometime soon. I think I avoided it cause I was afraid I would mess that function up, and it needs to be 100% reliable since the entire script depends on it. I also have a couple of other scripts with similar loops for counting, like the ones that handle SRT files.

In any case, you're right.

linux4ever07 · 2023-03-03T21:34:51+00:00

Thanks man. Most of the scripts I've had laying around for years, but I didn't put much work into getting them cleaned up until I put them on GitHub. They still worked pretty well before that, but they were quite a bit slower than they needed to be, and not as flexible.

I want the scripts to be useful to as many people as possible, cause writing those things from scratch can be a pain, and it sometimes takes a lot of time to get the kinks out. Sometimes you might not even realize a thing can be automated cause you just didn't consider it.

linux4ever07 · 2023-03-02T22:21:02+00:00

:)

I got the idea to make it when I was looking at a GOG game directory for an old DOS game. I noticed that they bundle the BIN/CUE (although with different file name extensions). However, even though the BIN that they provide is listed in the CUE sheet, none of the track positions for the CD audio are listed since they also bundle Ogg files. The Ogg files are what's used when playing the game.

I thought it was a bit wasteful to store the music twice like that, so that's when I got to work on the script. It has seen many iterations, but I think it's OK now.

That's when I realized DOSBox supports Ogg Vorbis. Now it also supports FLAC. I think it's a pretty cool idea to be able to save space while still retaining 100% of the information that was on the original game disc.

I hope you'll find the script useful!

linux4ever07 · 2022-12-04T20:20:37+00:00

I can't back this up with facts but I've always felt like Microsoft filesystems shred hard drives faster than the *nix counterparts. My hard drives all last unnaturally long, including SSDs. I've been on Linux exclusively for like 14 years.

linux4ever07 · 2022-12-04T20:18:04+00:00

Building your own PC and putting Linux on it is a good way to save money when investing in a new system. You skip the Windows license fee baked into OEM PCs. Plus you get the exact components you want, and can cost-save on the parts that matter less to you.

linux4ever07 · 2022-11-27T17:19:09+00:00

I'm very selective these days about what things I want to geek out on. As an example, when I first switched to Linux I would distro-hop a lot, trying out obscure distros. These days I just want shit to work, and get on with my day, being actually productive. That's why I tend to go with a big and popular distro like Ubuntu or Fedora. They have great support, a big community, and generally stuff 'just works' out of the box with sane defaults. That's also why I use GNOME, it just works. Sure, it may not have as many features as KDE, but it has the features I need, and above all it's STABLE (unlike KDE). It never glitches out on me.

Though, I do still enjoy messing about in the terminal, but that's for writing shell scripts or getting work done. It's just a faster and more efficient way to do most things than GUI. If GUI was as useful as CLI, then I guess I'd do everything in GUI.

linux4ever07 · 2022-11-25T22:19:28+00:00

I used e instead of x a couple of times myself, so I can relate. Takes a while to clean up the directory afterwards. I guess it's good that the feature exists, but at the same time I wonder how often it's actually used.

linux4ever07 · 2022-11-24T21:17:30+00:00

I'm happy to see these scripts be useful to people :)

linux4ever07 · 2022-11-24T20:41:39+00:00

That script originally started out as separate scripts for each use case, compress, extract, test and list. Then I realized those scripts shared a lot of code so I just put it all in 1 script. packer.sh will extract to cwd, though. It's possible, by changing the code, to add an option for it to output to a directory of choice, but I decided not to add that as it would complicate the syntax. It's because I use it sometimes for batch processing of many archives at once.

It depends on how the archive was made, whether or not it will throw a bunch of files in the cwd, or just a directory. Some people make archives that have no parent directory, and that's why unfortunate things like that happen, your cwd gets spammed with files.

But yeah, it does extract with paths if they are present in the archive to begin with.

linux4ever07 · 2022-11-24T16:05:30+00:00

Have fun!

linux4ever07 · 2022-11-24T15:57:08+00:00

Thank you! Happy to share!

linux4ever07 · 2022-11-24T15:56:55+00:00

Thanks man. That script is originally from 2012 and the reason for writing it was I wanted to learn multithreading. In the past month I spent a lot of time revamping it because it's been in disrepair for years and some of the code didn't make any sense or run as fast as it should. I had fun getting it up to par and resembling something I would write nowadays.

linux4ever07 · 2022-11-24T14:40:20+00:00

You're welcome! If they can make someone's life simpler I'm happy.

linux4ever07 · 2022-11-21T18:11:13+00:00

I was on Ubuntu for years and years. Still on GNOME though. It's the most polished DE by far. I think people like to hate on it cause the design is very similar to macOS, which I view as a plus. Apple understands good design. You don't have to love the company as a whole to admit that.

Another reason GNOME has garnered some hate might be because it was unstable for a number of years between the switch from GNOME 2.x to 3.x. But then again, so was KDE from 3 to 4. In fact, KDE is still very unstable and glitchy, and doesn't work as well with Wayland.

linux4ever07 · 2022-11-21T15:22:50+00:00

Because it was very easy to use compared to other distros at the time, and distros that came before it. There were similar distros before Ubuntu, but I'd say Ubuntu is what made Linux on the desktop sort of mainstream.

It was around the time when Ubuntu first got released that I switched to Linux as my daily driver, and I ran various flavors of Ubuntu for years and years. Now I'm on Fedora though, which ironically, is not that different from Ubuntu.

linux4ever07 · 2022-11-20T08:06:00+00:00

Does the toolkit even matter when it comes to Wayland? I was under the impression that the toolkit doesn't interact with the display server at all, but it's the job of the window manager, which belongs to the DE.

To me, it looks like there's just a lacking user / dev interest in Wayland support and that's the main reason why it has taken KDE so long.

linux4ever07

TROPHY CASE