19
Just tried and that's it! I tried a few options before, not sure if I overlooked this or misunderstood. But setting --extractor-retries 2 for testing does indeed only try 2 times. Thank you.
It's a bit too early and premature. There needs to be an alternative to fax first.
No. All you need to do is put them in the right place. If they are marked as missing, either they are not in the correct folder, not named correctly or are the wrong versions.
Note: You don't need all files that are marked as missing in this list. There are bios files from PSP and PS3, but you don't need them. You only need the 3 original PS bios files, 1 for each region: scph5500.bin, scph5501.bin, scph5502.bin . Make sure they are the correct versions. Easiest way to check that is with md5sum . Then compare it to the MD5 listed at documentation link I gave you earlier, which looks like these 490f666e1afb15b7362b406ed1cea246 . Its enough to just compare the first few and last few characters to make sure its correct.
Without getting creepy (I have only good intentions) I looked up your post history to see if you were a Linux user. I can see you was setting up Batocera at some point. It is entirely possible that the system you are using setup a different directory for the RetroArch bios "system" folder. Open RetroArch and lookup Settings > Directory > "System/BIOS" . The very first entry on this list shows where the system directory of RetroArch is setup for you. The Playstation bios files go in that folder.
Can you play any Playstation games? If not, its best to create a log file. I don't know what platform you are using, here is an overview of how to do that for all platforms you have installed RetroArch on: https://docs.libretro.com/guides/generating-retroarch-logs/
You replied to yourself, therefore I did not get any notification.
Just put the bios files in the system directory. They don't need to be scanned. If these are the correct files, then RetroArch will pick them up automatically from this place. All you need is to put those 3 bios files with .bin extension to system folder.
Then you can check if the bios files are missing or correct at Settings > Core > Manage Cores > "Sony - PlayStation (Beetle PSX HW)" or at the core you actually use. Scroll down to the list with the exclamation ~~points~~ marks (!) . They tell you which of them are either "Present" or "Missing".
You are 100% and completely convinced me. Right now I'm in the process of renaming the project and decided to rename the executable too. All your points are on point and is something I would probably say about other projects as well.
As for why I was reluctant to change project name was not only the Github links, in example in the executable and documentation of older version people downloaded. But also the default ignore file I am using with the script, that is created and read/written at "~/.local/share/ytdl" . It will probably annoy people who already downloaded and using it; and I hate that its doing it. But better I do it now that later.
So thank you for this suggestion and explanation.
Edit: I'm going with yt-dlp-lemon , as in easy peasy, lemon squeezy. Probably not as descriptive as you hoped for, but I don't think this is bad.
That's actually a good point, one that I made myself over other projects in the past. Guess I did not think through this entire thing. The script itself is kind of like what an alias means to be, a shorter and simple alias to a more complex command that already exist. In fact it started and got evolved from that. The script is not a project on its own like yt-dlp being independent from youtube-dl. But I admit this is a bad excuse.
I would like to keep the simple and short to remember ytdl executable name. And if anyone wants to, can still rename it to something else when installing. On the other hand the project title and how it is referred to as has ambiguity to it. Changing the readme and some descriptions and titles is not a big deal (in this early stage), but changing the path to the project comes at a huge cost, meaning the Github link.
I like the ergonomics of the Xbox controller a lot (not the original ;-) ), but it would be nice to get rid of the proprietary driver and Microsoft wireless adapter on my Linux PC. Plus it's missing motion sensors, which could be used in Switch emulation or for some cool custom control schemes for Steam games.
RetroArch has a dedicated directory for bios and system files. Usually the Playstation bios goes to "system" folder in RetroArch. It's described here, you need the correct bios files: https://docs.libretro.com/library/beetle_psx_hw/#bios
Wish you the best and good recovery. I assume you also use it as a stationary machine connected to the tv/monitor?
I hope too! I think they did not figure out how to make the controller not too big with the two touch pads, without sacrificing the other important elements. That was one of the deal breaker for the original Steam Controller, alongside the not that much optimal ergonomics in the hand. If Valve can pull off a Steam Controller 2 that is inline with the Steam Deck and is capable of replacing my Xbox controllers, then I would happily pay full price at launch (after reviews off course). It could be the ultimate game controller.
51
Today I'm here again to terrorize this community with my Bash scripts nobody asked for.
This new biggest is a script evolved from a much simpler version found at biggest.sh to something more complex and complete. Now there are even options to show a simple horizontal bar and relative percentage numbers instead the file size itself.
It's a script to control du command in combination with several other standard Linux utilities. I'm well aware of these alternative applications to help visualizing what the biggest files on the system are. Well, I like these kind of scripts and I like its not too much bloated. And especially the output as paths can be combined with other tools easily. It's also kinda fun doing this. Edit: Forgot to mention, it also reads stdin pipe, as output from another program like find in example.
Have a good day.
17
A week ago I started a little script to format the output of file and path listings from other programs. It got a little bit out of hand and I implemented lot of advanced features into the fmt commands; kind of a sub language to define how the output should be formatted and structured. Entire idea is to give it paths, process the stream (not the file content itself, but the path representing a file) and output them again.
fpath accepts two type of input: a) either as arguments like fpath *.txt or b) from stdin like ls -1 | fpath . With additional options and commands the output can be colored and reformatted to something entirely different. In example with -F option the advanced formatting is possible, such as fpath -F '{.size} {name}' as a simple example.
There is lot of functionality (based on Python, yes this is a Python script), such as {reverse}{name}{/reverse} to reverse font color and background of the segment that is enclosed by the command, a slice to get a subset as a range from the entire path {-1:}, or {center:80}text{/center} to add spaces to get centered text, or just {ext} to output the extension, {mime} to output the file mime type, or even execute arbitrary programs {!grep:a}{path}{/!} to reduce output that has an a in the path.
Did I over engineer it again? Or just ignore most stuff and use it with the most simple options, should be enough anyway: fpath -t -s red *.txt
11
fpath v0.2 + update v0.3: Reformat and stylize file path like text output. (Python, terminal)
(github.com)
Hi all. Yesterday I posted a program/script which is focused on path based text formatting, such as output from ls or find. Today I want to share new version. I'm proud, even though its limited in its usefulness, but today I solved an issue that was complicated to me (and a few other issues).
Linux command file is used to display file type and mime information, which is super handy. Reason why this was complicated to me is, as I want it to run only once for all paths together for performance reasons. For over thousand files instead taking more than a minute execution time, its down to under 2 seconds when displaying file type information (which includes spawning file process in the background). A few examples:
$ find Desktop/*.* -maxdepth 0 | fpath -F'{type} \t{name}'
text/plain append.cfg
text/plain dynamic.cfg
image/png nearest.png
image/png new.png
$ find Desktop/*.* -maxdepth 0 | fpath -a -F'{path}\n\t{file}'
/home/tuncay/Desktop/append.cfg
ASCII text
/home/tuncay/Desktop/dynamic.cfg
ASCII text
/home/tuncay/Desktop/nearest.png
PNG image data, 1920 x 1440, 8-bit/color RGB, non-interlaced
/home/tuncay/Desktop/new.png
PNG image data, 1920 x 1440, 8-bit/color RGB, non-interlaced
Update v0.3:
Rather than creating a new post, I want to note that I have a huge update. First off, the performance is increased drastically with recent optimizations. Even thousands of paths are now processed very fast (until operations reading from file system is involved).
Just to put into perspective: When I search and output list of paths with time baloosearch6 "a" in my home, I get 8468 files and it takes 0m0,048s. Now when I pipe that into fpath with default processing and without options, it takes 0m0,086s to process. But with a more complex command that involves reading file stats (like size and such) and colored output and a slice:
time baloosearch6 "a" | fpath -F'{.mode} {.size} \t{-3:-1}: {blue}{name} {}' -sred
it only takes 0m0,200s to execute! But using {file} or {type} or {mime} will still take a long time, even if the subshell process is run only once (it will still read the information for every file):
time baloosearch6 "a" | fpath -F'{file}'
took 3m54,233s to run. But what do you expect with approx. 8 thousand files. Without this script, it would take the same amount of time when running bare metal file command on all of these files.
Secondly, I have implemented a slice command that works very well. It's like the index {3} thing, but now you can set a {start:end} range to not only get a single part, but all parts within that range. It even works with negative numbers like {-3:} to get the last three parts of a path. An empty index means to get everything until end of path.
I'm quite happy how this program turned to be out. Python (at least for me with Python v3.12) is not that slow after all.
23
I did it again; exaggerate a simple idea and make it look more complicated at the end with too much text in the readme. I was bothered with the output of file listings and how unreadable they can get, especially with long paths and many of them on screen. At the end, I am not sure how useful this will be in the long run, but that is something you can judge yourself. It was certainly fun to create and in my opinion it's also fun to use.
git clone https://github.com/thingsiplay/fpath
cd fpath
chmod +x fpath
What is this? Convenience script to style and reformat the output with path like formats. Designed to combine listings from other programs output, such as from find and even ls, or any other tool with similar capabilities. The script works mostly on text data rather than the file system, but some special commands are exception to this rule and will access the file system.
view more: next ›
thingsiplay
joined 11 months ago
Besides that I don't like its installation is a curl into bash and then the script itself curls data from internet (from another repository https://github.com/HorlogeSkynet/thunderbird-user.js); not a good practice. But besides that point that get ignored anyway...
A tip: You can use in a single
sedcommand multiple-e. So you would need to run sed only once and load the file only once (or only a few times). Like this:sed -e 's/abc/ABC/g' -e 's/def/DEF/g' file.extand you can have each of them on their own line too:Why do you have so many huge block of whitespaces, such as 10 empty lines in row, multiple times throughout the script? An why are there so many unused lines of code, commented out? I think you should delete them completely to not confuse people. If you want do additional features people can use optionally, then either create options for that or create another script that can be run if its installed (check if file exists and then run it if user installed it).
These are just a few thoughts I had when looking into the code.