Update: I tried the feed without any filters , and it doesn't work. It fetches the .torrent link everytime and fails. It works on older releases that have .nzb though. Solution?
Comment in Feedback 12/11/2023 18:34 — Anonymous: "likeableyak"
I am trying to add RSS feeds to Sabnzbd. I search the filter and add the rss2 link from top right. My question is, when sabnzbd refreshes the feed and finds an anime while it hasn't been cloned to nzb and is only available on torrent, what will happen? (I dont have a reliable way to test this as of now). Or alternatively, any way to only include .nzb links in the feed?
Is this still the case? I can't see any issue with those search results unfortunately.
If it is still the case, could you supply: - an exact search text which has missing results - link to a result that should appear in the results, but doesn't
I haven't seen anything unusual in the logs in the 30 minutes prior to your post. Maybe a routing issue or similar; won't be able to tell with the info given.
Request to Admin: Please make a copy of 2020q1 Cinnamon theme to be available in the list as I think it's almost gone now. It's the only color I use since AT started or so ^^
> because the list of attachments for each file is already known. for each file or each subtitle file?
also about the in memory thing, yah i made a mistake, i remember telling myself to add "or streamed into memory" or something like that when writing the last part of the message but i forgot to.
but still you dont have to write your own (de)muxer, libavformat gets one packet of the file at a time and outputs one packet at a time, only problem is that i don't know c and looking at the docs and examples from ffmpeg.org hurts my head so i am looking into binding in other programming languages like python
You won't need to worry about this, because the list of attachments for each file is already known.
in memory
Well, not exactly, rather it needs to be streamed. Fully buffering the decompressed file in memory, and then creating an MKS in memory, would be undesirable due to RAM usage. For example, if the decompressed attachments total 100MB, then that's potentially 200MB of RAM used during the process. XZ decompression can be streamed and there are libraries that do this. The only thing you'd have to worry about is the muxer, which needs to accept streams as input and produce an output stream, without needing to buffer the entire output in memory.
hmm, so the mks script will need to - find the fonts used by the subtitle - decompress the `.xz` font files in memory - take that and mux it whit the subtitles into a mks file in memory - then stream that file to the client
ok, this is more of a pain then i first thought it would be, the more and more i look into doing this the harder it gets.
Fonts are often reused across files. Storing attachments individually enables deduplication, which saves a significant amount of disk space, and is why it's done this way. Storing them in some sort of packaged form (like in a Matroska container) means you can't take advantage of this form of deduplication any more.
For reference, the "All Attachments" link runs a script which locates the LZMA2 stream in each .xz file, and sends them out as a stitched .7z stream. As the .7z files don't actually exist on disk, it doesn't cost space, and the assemble process is fully streamed, so is eficient. An MKS link would need to work in a similar fashion.
oh, i was not thinking of backwards compatibility whit already extracted attachments and subtitles (at least i think that's what you were talking about in the above post), i think you should just keep all entry's whit the normal `ass.xz` unchanged. just new one would be processed into `mks.xz` or something
cant you just use ffmpeg or mkvmarge for the muxing / demuxing
The attachments are stored here individually as compressed .xz files. So you'd need a script that stitches the data together and streams the output to the client, when someone tries to download the MKS - writing temp files and invoking external processes would be far too slow.
> but writing a Matroska muxer involves a certain degree of complexity. cant you just use ffmpeg or mkvmarge for the muxing / demuxing
> I believe MKVMergeGUI picks up most of the stuff automatically by MKVMergeGUI i think you mean MKVToolNix GUI. but yes, i can just drag and drop the "attachments" folder into it and it detects everything
Thanks for the suggestion. The idea actually did cross my mind in the past, but writing a Matroska muxer involves a certain degree of complexity. But if you're willing to take on the challenge, it can be looked at.
for every file or make a script
If it helps, for single files, I believe MKVMergeGUI picks up most of the stuff automatically if you just drop them in the right place.
you should give the subtitles of a release in a mks file, so it can have metadata and attachments (fonts), i know there is "all attachments" download but to use it to marge stuff you need to manually do `-attach font.ext -metadata:s:num mimetype="font/whatever"` for every file or make a script, granted it wont be ~that~ hard to make but i am lazy
Did this actually happen....death threats? Death threats and telling someone to kill themselves is childish, immature and people who say such things are obviously unstable themselves. Anyone who has lost someone to homicide suicide or accidents have more class than to wish death upon others
Arguing is one thing but if someone actually threatened to kill someone or commit suicide the admin should ban their ip.
13/11/2023 12:08 — admin