Dalsze problemy z pobieraniem napisów (Napisy24?)

[andrewpros]

Nadal nie działa pobieranie odnośnie #46, tamta poprawka na pewno poprawiła omyłkowy brak w kodzie, ale jest inny problem.

Jak ustawię Napisy24 na pierwszej pozycji, a napi na drugiej to nie pobiera mi nic, a na obu serwisach są napisy pl do serialu na którym to testuje.

Mimo, że okienko m.in. wypisuje "rozpakowywanie" itp.

Gdy zamienię kolejność na napi, a potem napisy24 to działa.

Ba, jak włączę zawsze pokazywanie listy napisów to są na obu serwisach, czyli je znajduje, ale i tak nic nie zapisuje, jeżeli wybiorę te z napisy24, na końcu i tak będzie nie pobrano napisów.

Wygląda na to, że z obsługą napisy24 coś nie gra.

Dodatkowo tylko w jednym przypadku podświetla mi na zielono napis z listy (testuje na 3 odcinkach serialu), może warto się temu też przyjrzeć albo to może pomóc w diagnozie.

Sprawdziłem nawet snifferem, napisy24 zwraca, że jest ok i są napisy, no, ale w programie rezultaty takie jak opisałem. Sprawdziłbym lepiej debbugerem, ale nie chce mi ruszyć.

[krzemin]

Parę miesięcy temu z silnikiem Napisy24 był taki problem: #23. Do zipa wrzucali jakiś plik .url obok napisów i on był rozpakowywany zamiast napisów. Pierwsze podejrzenie to że znów wrzucają jakieś dziadostwo do archiwum.

Byłbyś w stanie podrzucić zipa pobranego z Napisy24? On jest zapisywany do katalogu tymczasowego (pod nazwą QNapi*.tmp) i rozpakowywany tutaj: https://github.com/QNapi/qnapi/blob/master/src/engines/qnapisy24engine.cpp#L418 (tmpPackedFile wskazuje na dokładną ścieżkę do tego pliku).

Możesz jeszcze spróbować z innymi plikami, niż seriale i zobaczyć czy błąd przy rozpakowywaniu jest tylko dla niektórych plików, czy zawsze dla wszystkich...

PS. A zamiast debuggera można w Qt używać qDebug() :)

[andrewpros]

Na teraz paczka 7z z Napisy24 http://www97.zippyshare.com/v/BYTe4Cj6/file.html 2 seriale i 2 filmy

Żadnego nie pobrało, a raczej nie zapisało, napisy są do wszystkich w ich bazie, w paczkach są tylko napisy.

Na teraz nie wiem co jest, ale wygląda, że coś jest w tej funkcji unpack nie tak, tylko dla napisy24 są tam zmiany dotyczące skrótów url, także może tam coś albo coś w strukturze plików 7z coś nie tak od nich.

[krzemin]

Paczki 7z, które pobrało są w porządku. Co więcej - u mnie funkcja unpack() rozpakowywuje je poprawnie.

[andrewpros]

Czyli coś systemowego? Czego program nie bierze pod uwagę?

Tylko jak to zdiagnozować i czemu akurat w przypadku n24?

Na oko bym powiedział, że coś może z uprawnieniami, ale no właśnie problem tylko z n24 występuje.

EDIT: Coś jest nie tak z projektem, bo na czystym debugger działa, jak naprawię debugger będę wiedział co jest nie tak.

EDIT: Rozpakowuje ok, ale czy był testowany cały proces, bo u mnie źle ustawia nazwy napisów i złą ścieżkę do pliku, to jest powód, rozpakowuje w miejsce które nie istnieje, z paczkami jest wszystko ok. (debugger już działa, testuję na win)

[krzemin]

W przypadku N24 rozpakowywanie napisów jest trochę uciążliwe, bo nigdy nie wiadomo jaka jest nazwa pliku z napisami wewnątrz archiwum i trzeba go skanować, osobnym wywołaniem 7zip-a, wyciągać nazwy plików wyrażeniami regularnymi, co może być trochę error prone.

Możliwe przyczyny to:

• wersja 7zip-a (mogła się zmienić i np. zmienić argumenty programu / składnię outputu) - mało prawdopodobne
• ścieżka do katalogu tymczasowego (albo jakaś inna) zawiera spacje, polskie znaki lub znaki specjalne, które nie są poprawnie kodowane/escape'owane
• program nie skończył rozpakowywania w ciągu 5s - na działanie procesu 7zipa założony jest limit czasu, jeśli nie zdąży rozpakować, to się wywala; zazwyczaj trwa to ułamki sekund, ale jeśli np. katalog tymczasowy masz na zdalnym systemie plików... :)
• albo inne, które na teraz nie przychodzą mi do głowy

Jak diagnozować? zapiąć debugger albo qDebug().

[andrewpros]

Znalazłem, ale nie wiem czemu nie działa u mnie, a u ciebie tak. Może nawet nikt nie zauważył, że to nie działa. Zrzut z debuggera by ułatwić rozeznanie

http://i.imgur.com/C8azoqD.png

To jest to miejsce https://github.com/QNapi/qnapi/blob/master/src/engines/qnapisy24engine.cpp#L456

Proces idzie tak jak opisałeś, skanowanie o nazwę itp.

Wyłapuje dwa matche do pathMatches, ale robi potem first(), a jak weźmiemy nazwę napisów które są pod indexem 1, czyli last() to działa.

P.S. W pliku .pro jest wpisany na stałe release, dlatego z miejsca nie działa debugger, a ja przy pierwszym usunięciu tego release nie zrobiłem rebuilda. (nie jestem specem od qt, dlatego też wolę debugger, widzieć wszystko na żywo niż qDebug)

[andrewpros]

Tak pomyślałem, może lepiej szukać w n24 tylko plików z końcówką srt, txt itp. zawsze będzie tylko jeden taki plik albo szukać pliku z nazwą pliku materiału, bo tak chyba odsyła, bo teraz to dość dziwnie działa, a przecież katalogi i nazwę pliku znamy.

[krzemin]

Zobacz ifa wewnątrz pętli (filePath != tmpPackedFile) - on powinien wyciąć pierwszą sciezke. Bardziej przyjrzalbym się temu, dlaczego nie wycina.

[andrewpros]

Nie wycina, bo filePath != tmpPackedFile. Są takie same.

[andrewpros]

Listowanie paczki zwraca

"7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18

Listing archive: X:\temp\QNapi.41.tmp

Path = X:\temp\QNapi.41.tmp
Type = zip
Physical Size = 27616

---

Path = A.Walk.Among.the.Tombstones.2014.BDRip.x264-SPARKS.txt
Folder = -
Size = 58703
Packed Size = 27410
Modified = 2015-01-06 12:44:22
Created =
Accessed =
Attributes = .....
Encrypted = -
Comment =
CRC = 5B147DF5
Method = Deflate
Host OS = FAT
Version ..."

Regex wyszukuje Path, są dwa, zawsze, pierwszy jest taki sam jak ścieżka do pliku tmp.

A więc zawsze ten kod

if(filePath != tmpPackedFile && !filePath.endsWith(".url"))
{
pathMatches << filePath;
}

Doda pierwszy znaleziony Path także, bo pod tmpPackedFile jest to samo.

Rozumiem, że w tamtej linijce jest first(), bo oczekuje że zawsze będzie tylko jeden wynik, nie będzie i to tam musiało być już jakiś czas, ten kod jest wadliwy.

Nie wiem czemu tak, w ogóle nie znałem cmd 7z, nie do końca czaiłem czemu tam jest regex, teraz jak ogarnąłem, skapowałem o co biega i co nie gra.

Ten kawałek kodu trzeba usprawnić. Może po prostu skoro i tak sprawdza końcówkę, sprawdzać dodatkowo txt lub srt i tyle, wtedy jest pewność i nie ma tego porównania.

[krzemin]

Ale zauważ, że właśnie gdy w pętli mamy filePath == tmpPackedFile, to nie wchodzimy do ifa, nie dodajemy tej ścieżki do pathMatches i powinniśmy skończyć z jednym wynikiem. One czymś się różnią, nie wiem - może jakiś znak końca linii wyciagnelo regexem albo slashe/backslashe. Najlepiej to pewnie byłoby brać nie pełne ścieżki, ale porównywać tylko nazwy plikow.

[andrewpros]

No dobra, ale jako to mam rozumieć, że niby mój system coś jest nie tak? Nic nie zmieniałem w kodzie, system mam standardowy win 8.1 x64 bez żadnych nakładek, dziwnych konfiguracji itp.

Nie sugeruje zamienić != na ==, tylko pozbyć się tego, bo jest podatne na problemy, wprowadzić bardziej sprawdzony sposób skoro jest problem. I jak będzie == to będzie to samo, wejdzie do ifa, czemu uważasz, że nie, jak jest != to nieprawda, wejdzie, jak jest == to prawda, znowu wejdzie, bez względu na porównanie wchodzi.

Bo ja nie wiem po co w ogóle tam jest to porównywanie jak lepiej sprawdzać końcówkę i tyle.

Jak pisałem, nie znałem się na cmd 7z, sprawdziłem co zwraca listing i on zawsze zwraca dwa Path, pierwszy to jest ścieżka do pliku tmp, drugi to zawartość w postaci nazwy pliku, w tym wypadku jest jeden plik, więc Path w sumie będą dwa i to wynika z kodu i z tego co ten listing zwraca.

A, że tmpPackedFile zawsze jest równe ścieżce do pliku tmp to zawsze filePath != tmpPackedFile nie zostanie spełnione i doda do wyników na pierwszej pozycji złą wartość, ścieżkę do pliku tmp, gdzie program oczekuje tylko jednej wartości w tablicy, robi first(), a są dwie.

Być może chodzi o to, że regex wyłapuje nowe linie i w pewnych przypadkach to się nie sprawdza? Może listing z 7z się zmienia czasami w zależności o konkretnego systemu? Choć jak napisałem, są dwa Path i to jest prawdziwy problem, że 7z jako pierwsze zawsze daje ścieżkę do paczki, która jest taka sama jak tmpPackedFile.

Bo de facto dokładnie to zwraca takie coś, tylko ja dla czytelności wrzuciłem z \r\n zamienionymi na nowe linie

"\r\n7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18\r\n\r\nListing archive: X:\temp\QNapi.12287.tmp\r\n\r\n--\r\nPath = X:\temp\QNapi.12287.tmp\r\nType = zip\r\nPhysical Size = 27616\r\n\r\n----------\r\nPath = A.Walk.Among.the.Tombstones.2014.BDRip.x264-SPARKS.txt\r\nFolder = -\r\nSize = 58703\r\nPacked Size = 27410\r\nModified = 2015-01-06 12:44:22\r\nCreated = \r\nAccessed = \r\nAttributes = .....\r\nEncrypted = -\r\nComment = \r\nCRC = 5B147DF5\r\nMethod = Deflate\r\nHost OS = FAT\r\nVe..."

Po za tym jaka jest gwarancja, że w innych serwisach nie zaczną dorzucać innych plików do paczki?

Więc według mnie lepiej to zmienić na sprawdzanie po rozszerzeniu, by nie było nigdy już wątpliwości, funkcję przenieść do abstrakcyjnego rodzica i dodać ten krok w każdym obsługiwanym serwisie, zabezpieczając się przed dodaniem gdziekolwiek niepotrzebnych plików.

Bo przecież ten kod i tak nawet dla n24 to jest zbędna pozostałość, już nie dorzucają url.

[krzemin]

Każdy silnik pobierania ma swoją funkcję unpack(), bo różne serwisy pakują archiwum na swój sposób. Np. w NapiProjekcie nie ma konieczności listowania plików z archiwum, bo tam plik ma nazwę zgodną z checksumą, którą znamy wcześniej.

Bo przecież ten kod i tak nawet dla n24 to jest zbędna pozostałość, już nie dorzucają url.

Jakieś oficjalne źródło, link do dokumentacji? Bo do tej pory w większości archiwów były tylko napisy, ale do niektórych dorzucali jakieś śmieci typu .url.

Co do tamtego ifa - problem dotyczył backslashy. Zmienna filePath: miała wartość X:\temp\QNapi.41.tmp, podczas gdy tmpPackedFile - X:/temp/QNapi.41.tmp. To jest przyczyna, dla której obecne rozwiązanie nie działało. I wygląda na to, że problem dotyczył tylko Windowsa.

Przerobiłem to zgodnie z Twoją sugestią, aby wyszukiwać plik po rozszerzeniu. Powinno działać wszędzie i być mniej problematyczne.

[andrewpros]

Wiem, że jest osobny kod unpack dla każdego serwisu. Ścigałem po prostu z n24 już dłuższy czas do wieli materiałów bez qnapi i nigdy nie miałem pliku url, może zmienili to zanim zacząłem używać ich programu, nie wiem, teraz chciałem się przerzucić na coś lepszego.

Ale oficjalnej wypowiedzi nie mam.

I nie wiem dlaczego uważasz, że problem dotyczył backslashy, u mnie obie te zmienne miały dokładnie tą samą wartość, co zresztą opisałem, więc to nie była przyczyna.

Ale skoro poprawione to już nieważne.

[krzemin]

Gdyby miały tę samą wartość, to nie weszłoby do ifa (warunek != byłby niespełniony) i nie miałbyś problemu z unpack-iem.

Rozwiązanie z przeszukiwaniem rozszerzeń będzie odporne na .url i jakiekolwiek inne śmieci w archiwum.

Skoro problem rozwiązany, zamykam wątek.

[andrewpros]

No tak, już mi się kompletnie pomieszało, było tak jak napisałeś, działa już ok.

[uded]

Witam, ja chyba po tej samej sprawie...

Od pewnego qnapi z serwisu Napisy24.pl pobiera i tworzy mi plik URL zamiast właściwych napisów. Zawartość, dla przykładu, taka:

[InternetShortcut]
URL=http://napisy24.pl/
Modified=60E35C9CA7B9C90165

Czyli prawidłowy, zgodny z oczekiwaniami plik URL. Ale napisów brak. Po przeczytaniu tego wątku zajrzałem do /tmp i napisy do filmu tam znalazłem. Są, jak byk, plik TXT zgodnie oczekiwaniami.

Drobne sprawdzenie co i jak i mam podejrzenie, skąd mi się ten przypadek wziął. Otóż jedyna różnica, jaką znalazłem, ogranicza się do nazwy pliku. Zatem pobieram napisy do pliku Moj.Zajefajny.Serial.S01E04.HDTV.x264-Team[strona].mkv a plik w katalogu /tmp ma nazwę: ``Moj.Zajefajny.Serial.S01E04.HDTV.x264-Team.mkv`. Czyli, jak podejrzewam, ten mały dopisek w nawiasach kwadratowych doprowadził QNapi do stanu szoku i nie pozwolił na przeniesienie napisów do folderu docelowego.
W innym przypadku różnica dotyczyła nie tylko tego dodanego fragmentu do nazwy pliku, ale także wielkości znaków nazwie - ale to chyba nie ma znaczenia. A w jeszcze innym nazwa pliku miała się już zupełnie ni jak do filmu. Ale powód, być może, nadal ten sam...

Dodam, że używam qnapi jako aplikacji CLI, bez GUI.

[l0co]

Potwierdzam błąd, plik .url pojawia się w katalogu z filmem, plik z napisami w /tmp. Dotyczy tylko pobierania z napisy24. Nie ma znaczenia nawias kwadratowy (u mnie nie ma takiego nawiasu w nazwie filmu).

Dodam jeszcze że to raczej coś po stronie napisy24 zmienili, bo xmbc/kodi też nie pobiera z tego serwisu od jakiegoś czasu.