Hi!
Got pyrescene working just fine on Debian Jessie x64.
I just cd to the directory of the avi/mkv/media file, and run "srr filename.srr" but doing this with whole seasons of tv-shows will take forever. And i just can't figure out how to reconstruct multiple releases at once! Must be a simple way to do this?
// tbt
Check the download page:
https://github.com/dryes/rescepy
https://github.com/sfinxen/AutoResceneJ/releases
This isn't something that's part of the pyReScene package yet. Only creation is well automated.
I've been having this problem lately, but with releases that only contain one big .iso file. Even weirder, in the case of "Windlands-SKIDROW" the last rar part is larger in the reconstruction than in the original. My .r31 is 8,040,308 bytes, while the original is supposed to be 8,040,290 bytes.
I have the extracted files for the following:
DanMachi.E01.Abenteurer.German.2015.ANiME.DL.1080p.BluRay.X264-3MiNA
DanMachi.Is.It.Wrong.To.Try.To.Pick.Up.Girls.In.A.Dungeon.E02.Monsterfestival.Monsterphilia.German.2015.ANiME.DL.1080p.BluRay.X264-3MiNA
DanMachi.Is.It.Wrong.To.Try.To.Pick.Up.Girls.In.A.Dungeon.E03.Goetterklinge.Hestia.Knife.German.2015.ANiME.DL.1080p.BluRay.X264-3MiNA
3MiNA-DanMachie03-1080p.mkv
3MiNA-DanMachie02-1080p.mkv
3MiNA-DanMachie03-1080p.mkv
Can someone create an .srr please?
Ok so i have a rar release with 2 rar files thats corrupted in some way. Is it possible in any way to restore those so i can unpack it?
Not with the .srr file because then you need to have the extracted content already.
Try the following:
If you want to create a scene group for releasing music, nothing of the rescene project is relevant for doing that.
The point of this wiki is to provide help with the steps involved to create the meta data backups. It's all explained here on various pages.
If you already struggle with this, you have still a lot to learn before ever being in a scene group.
The final 0.6 release supports VOB samples. The SRS files can also be reconstructed.
When a .vob is a renamed rar volume, a .srr file is created too.
SRS files for .m2ts can be created, but won't be able to reconstruct. It'll only work in rare cases. (due to improper sample creation I guess)
I saw this same behavior with http://www.srrdb.com/release/details/Hearts.Medicine.Time.to.Heal.GERMAN-0x0815
0eae752b 06cfcfcf hf-hmtthde.iso D:\_\hf-hmtthde.r38
But the last file actually reconstructed correctly and didn't fail the SFV.
That release is related to this issue: https://bitbucket.org/Gfy/pyrescene/issues/107/hi2u-and-reloaded-rar-files
I notice that another message is suppressed: "CRC mismatch in file: " (that's a bug)
It means that the archived files you are packing don't match the SRR. Or the RARs aren't made with WinRAR as in the above release.
That line was always displayed on compressed RARs. The compressed data would not match the uncompressed file.
https://bitbucket.org/Gfy/pyrescene/commits/c56363a4975c785f767de3b6865757dfe35a9773
I have several missing samples from full.bluray releases.
Is it not possible to reconstruct from the .srs because of lack of M2TS support?
Yes, it is not possible yet. The .srs is just the bare minimum with the original file name and CRC32 hash.
I've looked at it, but there's a bunch of header stuff that changes in the sample. It's more complex than just putting the track data back at the right places and I don't find the proper documentation for it. I'll have to look at the source code of other tools and experiment some more.
"ValueError: Still not fine :("
Try playing with the new --mt-set option!
e.g. --mt-set 4,6,8 when it failed on rar.exe -mt2
https://twitter.com/pyrescene/status/752530233614540801
Hi guys!
It is known that pyReScene tries to find out the correct rar version when reconstructing compressed rars by trial and error; the code for this is experimental. I would like to suggest to discuss possible improvements to this basic trial and error approach.
One straightforward possibility would be to go through the process of trial and error at the time of creating an .srr file, find out (if possible) the rar version used for compression by checking in a repository containing rar executables of all different versions available at that time, and adding this tiny (optional) information to the .srr file. Whenever the correct version can't be found at the time an .srr is created one would fallback to the trail and error process later when needed. This needs more time and computational power when creating .srr files, but once it is done every user can benefit from it later if the used rar version is found and incorporated into the .srr file.
Would it be possible to add an optional field to the .srr format to store a rar version used during compression? What other options do we have to improve the problem of discovery of rar versions?
This is never going to be default behavior for SRR creation, but an option for this can be possible. It'll extract the release and do the search up front. This is similar to the SRS files. Another possibility is to always modify the .srr when a release was successfully reconstructed. Then something to make sure the file gets uploaded again.
I've reserved a block for this in the file format.
Another idea is to store the .cue and some other small files up front. Then you always have the right files to start from. (and maybe in their compressed form to not having to check them)
Hello, I am trying to reconstruct Abes_Exodus_CD2_REPACK-FLT with no success, I have gotten the following error:
H:\Abes_Exodus_CD2_REPACK-FLT>"C:\Program Files\reScene\srr.exe" H:\Abes_Exodus_CD2_REPACK-FLT\Abes_Exodus_CD2_REPACK-FLT.srr -z "C:\Program Files\reScene\rar"
Traceback (most recent call last):
File "E:\pyReScene\rescene\srr.py", line 566, in main
File "E:\pyReScene\rescene\srr.py", line 307, in manage_srr
File "E:\pyReScene\rescene\main.py", line 1301, in reconstruct
File "E:\pyReScene\rescene\main.py", line 1690, in get_rar_data_object
File "E:\pyReScene\rescene\main.py", line 1976, in compressed_rar_file_factory
File "E:\pyReScene\rescene\main.py", line 2101, in init
File "E:\pyReScene\rescene\main.py", line 2337, in search_matching_rar_executable
File "c:\Python34\lib\genericpath.py", line 50, in getsize
FileNotFoundError: [WinError 2] The system cannot find the file specified: 'C:\\DOCUME~1\\user\\LOCALS~1\\Temp\\SRR-lc56v7nj\\pyReScene_data_piece.bin'
Unexpected Error: [WinError 2] The system cannot find the file specified: 'C:\\DOCUME~1\\user\\LOCALS~1\\Temp\\SRR-lc56v7nj\\pyReScene_data_piece.bin'SRR file created with pyReScene Auto 0.5.
Re-creating stored file: flt-newae.nfo
Re-creating stored file: abecd2_ok.sfv
Re-creating RAR file: abecd2_ok.rar
Trying to rebuild compressed file abe2_ok.bin.
I tried another one - Hitman_2_Update_1.01-FLTDOX with no success either:
H:\Hitman_2_Update_1.01-FLTDOX>"C:\Program Files\reScene\srr.exe" H:\Hitman_2_Update_1.01-FLTDOX\Hitman_2_Update_1.01-FLTDOX.srr -z "C:\Program Files\reScene\rar"
SRR file created with pyReScene 0.5.
Re-creating stored file: fdx-h211.nfo
Re-creating stored file: fdx-h211.sfv
Re-creating RAR file: fdx-h211.rar
Trying to rebuild compressed file hitman2.exe.
Grabbing large enough data piece size for testing.
Trying 2002-12-07 3.10.
Good RAR version detected: 2002-12-07 3.10
C:\Program Files\reScene\rar\2002-12-07_rar310b5.exe a -m5 -mdG -s -ds -vn -o+ -ep -idcd C:\DOCUME~1\user\LOCALS~1\Temp\SRR-g0x8k7mi\pyReScene_compressed.rar H:\Hitman_2_Update_1.01-FLTDOX\hitman2.exe H:\Hitman_2_Update_1.01-FLTDOX\hitman2_101_en.exe
Compressing hitman2.exe…
RAR 3.10 beta 5 Copyright (c) 1993-2002 Eugene Roshal 7 Dec 2002
Shareware version Type RAR -? for help
Evaluation copy. Please register.
Creating solid archive C:\DOCUME~1\user\LOCALS~1\Temp\SRR-g0x8k7mi\pyReScene_compressed.rar
Adding H:\Hitman_2_Update_1.01-FLTDOX\hitman2.exe OK
Adding H:\Hitman_2_Update_1.01-FLTDOX\hitman2_101_en.exe OK
Done
Trying to rebuild compressed file hitman2_101_en.exe.
Compressing fdx-h211.nfo…
RAR 3.10 beta 5 Copyright (c) 1993-2002 Eugene Roshal 7 Dec 2002
Shareware version Type RAR -? for help
Evaluation copy. Please register.
Creating solid archive C:\DOCUME~1\user\LOCALS~1\Temp\SRR-g0x8k7mi\pyReScene_compressed.rar
Adding H:\Hitman_2_Update_1.01-FLTDOX\hitman2.exe OK
Adding H:\Hitman_2_Update_1.01-FLTDOX\hitman2_101_en.exe OK
Adding H:\Hitman_2_Update_1.01-FLTDOX\fdx-h211.nfo OK
Done
Solid archive recompression.
ERROR: Unknown option: mt1Something went wrong executing Rar.exe:
Command line option error
ERROR: Unknown option: mt2Something isn't right yet.
Something went wrong executing Rar.exe:
Command line option error
C:\Program Files\reScene\rar\2002-12-07_rar310b5.exe a -m5 -mdG -s -ds -mt2 -vn -o+ -ep -idcd -v2809543b C:\DOCUME~1\user\LOCALS~1\Temp\SRR-bvork056\pyReScene_method2.rar H:\Hitman_2_Update_1.01-FLTDOX\hitman2.exe H:\Hitman_2_Update_1.01-FLTDOX\hitman2_101_en.exe H:\Hitman_2_Update_1.01-FLTDOX\fdx-h211.nfo
Compressing ALL files.
Command length: 16
ERROR: Unknown option: mt2Traceback (most recent call last):
File "E:\pyReScene\rescene\main.py", line 1962, in compressed_rar_file_factory
File "E:\pyReScene\rescene\main.py", line 2423, in set_new
ValueError: Something isn't right yet.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "E:\pyReScene\rescene\rar.py", line 1395, in init
FileNotFoundError: [Errno 2] No such file or directory: 'C:\\DOCUME~1\\user\\LOCALS~1\\Temp\\SRR-bvork056\\pyReScene_method2.rar'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "E:\pyReScene\rescene\srr.py", line 566, in main
File "E:\pyReScene\rescene\srr.py", line 307, in manage_srr
File "E:\pyReScene\rescene\main.py", line 1301, in reconstruct
File "E:\pyReScene\rescene\main.py", line 1690, in get_rar_data_object
File "E:\pyReScene\rescene\main.py", line 1983, in compressed_rar_file_factory
File "E:\pyReScene\rescene\main.py", line 2578, in init
File "E:\pyReScene\rescene\main.py", line 2605, in set_file
File "E:\pyReScene\rescene\rarstream.py", line 76, in init
File "E:\pyReScene\rescene\rarstream.py", line 44, in _check
File "E:\pyReScene\rescene\rar.py", line 1397, in init
rescene.rar.ArchiveNotFoundError: [Errno 2] No such file or directory: 'C:\\DOCUME~1\\user\\LOCALS~1\\Temp\\SRR-bvork056\\pyReScene_method2.rar'
Unexpected Error: [Errno 2] No such file or directory: 'C:\\DOCUME~1\\user\\LOCALS~1\\Temp\\SRR-bvork056\\pyReScene_method2.rar'Something went wrong executing Rar.exe:
Command line option error
Are there any solutions for these reconstruction problems?
Maybe, but compressed reconstruction is all experimental code without known bugs fixed yet.
I see you're using a beta: 2002-12-07_rar310b5.exe. Try on the stable releases only first. It looks like it doesn't support the -mt# options. There likely is an older or newer version that'll behave the same as this beta. Make sure it finds those first to try on.
I excluded all betas and tried once again: srr.exe finds good rar versions however all of them (2005-10-07_rar351 and below that version) do not have the -mt# option leading to the same previous error.
I've found out that this option appears starting with 2006-08-05_rar360, yet from this version and upwards srr.exe does not find any good rar versions for reconstruction. So, older (marked as good) versions might be able to reconstruct the release but -mt# breaks the execution, then why srr.exe adds this option for older rars which do not even have it? Is the any way to skip this option for older rars?
When reconstructing an mp3, srs.py failed with these output:
srs.py 04_red_moon-cmg.srs 04_red_moon-cmg.mp3
SRS Load Complete… Elapsed Time: 0.00s
Track Location Complete… Elapsed Time: 0.00s
Track Extraction Complete… Elapsed Time: 0.02s
Warning: File ./04_red_moon-cmg.mp3 already exists.
Do you wish to continue? (Y/N): Y
Rebuild Complete… Elapsed Time: 0.06s
File Details: Size CRC
--- --
Expected : 14 876 724 646DF473
Actual : 14 876 724 766E89AE
Music track not deleted!
Help, please!
Rebuild failed for sample: 04_red_moon-cmg.mp3
This means that after fixing the tagging on your mp3 file it didn't match with the CRC32 of the file which the SRS was created from. In this case it won't overwrite the existing file in place.
Your track has some other issues besides bad tagging. e.g. flipped bit(s)