[情報] Hentai@Home 1.3.0 上線

看板AC_In (裏洽 18+動漫)作者Fortis931 (吾手發炎其形微賤)時間9年前 (2016/10/02 12:26)推噓13(13推 0噓 47→)

留言60則, 18人參與討論串1/2 (看更多)

Posted Sat, 01 October 2016, 10:17 UTC by Tenboro 文靠北長沒用過或是沒興趣的可以左轉大神留下！ Feature Additions - The H@H Downloader has made a surprising yet glorious return. This again allows you to download full galleries with H@H, except it is now fully automatic; the old .hathdl files are a thing of the past. ↑H@H 下載器強勢回歸，透過它可以下載完整的畫廊，這是預設如此 (燙波羅文法怪怪der) .hathdl成為過去式 The new Downloader works in conjunction with the Archiver, and uses the same GP/quota system. Thenloads will no longer eat from the image limit nor suffer from the old hitrate-dependent waiting periods. This makes things a lot simpler and more reliable, and allows galleries to be downloaded much faster than before. ↑新下載器以壓縮包型式下載，沿用以前的GP/額度系統這些下載不再受限於以往的圖片限制以及hitrate等待週期變得更加簡單也更穩定也還要更快 Support was added to download any of the six resolution options. It is also not subject to the 25% limit for resampled archives; as long as at least one file will be resampled with a given option, it is available. Like the Archiver, it obeys your Gallery Name Display setting. 只要檔案有支援這選項的話。(我必須承認不知道這段在講什麼) 壓縮包命名則依循你的畫廊設定 (全羅馬拼音or原文title) You will notice some new buttons at the bottom of the Archive Download popup,one for each resolution option. Clicking any of these buttons will queue the download for your client, which will start downloading it automatically within a couple of minutes. ↑客倌將會發現畫廊的Archive Download頁面有新的解析度選項彈粗奶點下它將會自動排程到你的H@H客戶端 (不是下載器) 下載能在短短幾分鐘內完成 If you have multiple clients, you will have to select your default downloading client from the H@H page by checking "Use this client for the H@H Downloader" on the desired client on the bottom of the client settings page. If you only have one client, doing this is optional and will have no effect. ↑如果你有多個客戶端則需要為下載器在H@H頁面選擇想要對應的客戶端如果只有一個H@H客戶端則無須如此 By default, the Downloader will limit download speeds to your throttle setting. Speed limits can be disabled globally with the "Disable Client-Side Speed Limit" checkbox or --disable-bwm argument, or separately for downloads with the new --disable-download-bwm argument. ↑預設情況下，H@H下載器依循設定的限制下載速度限速可在「Disable Client-Side Speed Limit」勾選欄取消或以參數的形式取消它 The Downloader will not count towards nor honor the hourly bandwidth limit setting, so if you have a data traffic cap on the connection, you may want to be careful considering how much faster the new Downloader is. ↑H@H下載器不會去鳥你的當前下載隊列數或是頻寬限制設定（？）所以若你的網路卡成翔，你可能要看看是否H@H下載器跑太快了 At the end of each gallery download, the Downloader will report any failed downloads to the H@H servers. This is not currently used for anything, but in the future this will be a factor in trust/quality calculations. ↑每個畫廊下載的結束時H@H下載器都會回報H@H Server是否有失敗的下載這目前不會有作用，但未來計入 trust/quailty 的公式裡（H@H 客戶端？） While file requests that can be handled by the downloading client will usually be redirected back to itself by requesting it from localhost, files downloaded with the Downloader will notgeneral be added to your cache, as H@H now uses static ranges exclusively. ↑（這段繞口令我要請萬神殿的掃地阿伯翻譯...） Therefore, downloading files with the Downloader will have zero effect on the hitrate; the feature is solely a convenience bonus for running H@H, not a way to fill the cache faster than normal. ↑因此，透過H@H下載器對H@H客戶端的hitrate沒有影響這功能是單純給有在跑H@H客戶端的用戶的福利並無法加速填滿H@H客戶端的快取 - Added --cache-dir, --temp-dir, --data-dir, --log-dir and --download-dir arguments that allow you to change the locations of these directories without faffing with symlinks or mount points. Quotes are required if there are spaces in the path. H@H will attempt to create the directory if it does not exist. ↑H@H客戶端/下載器加上各種路徑參數讓用戶可以自訂想要的路徑如果路徑有空格存在則參數必須用引號括住若路徑不存在則會自動建立 linux usage: --cache-dir=/some/cache/location --temp-dir=/dev/shm/hath --log-dir=/dev/shm/hath windows usage: --download-dir="c:\some download dir with spaces" ↑（預設路徑我記得H@H客戶端不是都把路徑放它資料夾下面嗎？） Using a ramdisk for the log and/or temp folders will slightly reduce the I/O for the client, at the expense of storing logs and/or temp files that are currently being downloaded in RAM. ↑以RAMdisk存放log＆temp可以減輕H@H客戶端的I/O負擔 You can set the temp and log directories to the same path. However, if you choose to specify the data/cache/download directories, you should use unique paths for these. ↑用戶也可讓log與temp路徑相同但是data/cache/download路徑應該分開 - Added the --flush-logs argument that makes the logger flush the log to disk for every written line, which is useful for people who like to analyze their log live. This will increase I/O, and is mostly recommended for when the log is writtento a ramdisk. ↑加上--flush-logs參數讓日誌能逐條紀錄，給那些喜歡看日誌的紳士此舉將增加I/O負擔，建議用在RAMdisk ↓技術細節不翻↓ Memorial Wall of Internal Changes, Improvements and Fixes - The cache handler has been completely rewritten and no longer depends on SQLite. As the client no longer needs to send a list of files to the server, we can now make due with filesystem metadata and an optional in-memory cache to implement the LRU mechanism. - Most of the socket/file handling stuff has been rewritten to use NIO channels and buffers, reducing buffer copying overhead and CPU usage. - The bandwidth limiter has been rewritten to use byte buckets with 20ms resolution instead of a fixed delay per packet, which should make it much less prone to excessive sleeping on the job. Note that if the connection is mostly idle, this change can make transfers that only take a small fraction of a second complete faster than the speed limit would suggest. - Switched to using two levels of redirection for the file cache to avoid problems with very large caches. This means that every static range now has its own separate directory. - The LRU cache now uses bits 16-39 instead of 0-23 to avoid the grouping effects caused by static ranges. - Static range and H@H downloader file requests will now get a direct URL to a suitable image server or H@H client rather than having to go through the EH cluster redirection, which is both more efficient and more reliable, and avoids problems caused by factors like routing failures, blacklists and temporary IP blocks. - The receiving speed tester used to test other clients on behalf of the network no longer stores the received junk data in memory for no particular reason, instead the data is discarded as it comes in. - The sending speed tester will now create a small buffer of random data and reuse it, rather than burn CPU cycles to generate the up to 25 MB of random data required. - Validating proxy downloaded files is now done in parallel with downloading them, reducing peak CPU/RAM usage and eliminating some wasted I/O. - Rather than fully buffering downloading files to RAM before writing them to disk, we now write them to disk as the data arrives, which decreases peak RAM usage. As long as the OS has free RAM available, this will not significantly increase actual disk I/O due to OS-level caching and buffering, but if you want something close to the old behavior, you can point the temp folder to a ramdisk. - Maximum supported file size is now 4 GB. Which ought to be enough for everyone. Initially this is soft capped to 100 MB, but can be increased server-side withouta client update. - During the initial cache scan, we now check that the filesize for every file is correct, as a form of cheap file verification. For a full verification, you can still use --verify-cache. - Revalidating files on startup with --verify-cache is now far more efficient memory-wise. - The log directory is now separate from the data directory, mostly to make it easier to point the logs to non-persistent storage. As we no longer use a backing database, the only current use for the data directory is the client_login file, but unlike the logs we do want that to be persistent. the log file will no longer be opened or created at startup. - After startup, H@H now uses the provided list of RPC servers from the initial contact directly instead of relying on the DNS lookup to rpc.hentaiathome.net. This should significantly improve resiliency if any of the RPC servers are unvailable, and also eliminates problems caused by flaky DNS servers. - Server check-in frequency was increased from 300 seconds to 110 seconds. - Rewrote all the other things as well. - (GUI) The logpane was tweaked to avoid gobbling up massive amounts of RAM wh enthe log was scrolling quickly. To enable this, the H@H window is now fixed size. to avoid the overhead. - (GUI) The graph now shows the 60-second average line only for improved visiblity. It was also tweaked to improve the way it is drawn in general. - (GUI) Various minor visiblity improvements. The tacky connection/speed bars were also discarded in favor of a plain connection readout and the improved speed graph. - (Server) Added checks to prevent clients from being speed tested excessively often. - (Server) Brand new clients now start at 1500 historic/lomark/himark quality instead of 0, meaning that they'll get going faster than before. - (Server) For new clients, we now require at least 5 Mbit/s of both download and upload bandwidth, with 200 KB/s and 10 GB of disk space reserved for H@H. ↓重要必看↓ Notes (READ BEFORE UPGRADING) H@H 1.3 requires Java SE 7 or later to run. This is a version bump from 1.2.6, which could run on Java 6. ↑H@H客戶端/下載器 1.3版需要JAVA 7 以上環境 The 1.3 branch should be considered experimental/unstable and has a lot of new and rewritten code. If you are not comfortable with this, please stick with 1.2.6 for now. ↑請將1.3版試作實驗性的重製品如果你不喜歡1.3版，請先暫時退居1.2.6版 1.3 and future versions of H@H will not support the proxy functionality. While this option will eventually be removed from the site, trying to use this on a 1.3 client will not work. ↑1.3版及其往後版本將不支援proxy功能，網站最終也將移除proxy功能試圖在1.3使用proxy也是沒用的（android的裝置要哭哭惹） The first startup with this client will take longer than normal, as it will have to reorganize the cache and delete the now unused files that are not in the client's list of static ranges. ↑第一次啟動1.3版的H@H客戶端將會花費比以往更久的時間因其將重分配快取與刪除不在客戶端上的檔案 Because of this reorg, it is not trivial to revert to H@H 1.2.6, as you would have to manually collapse the cache tree from two to one directory levels. ↑因為重分配的關係，H@H客戶端從1.2.6升到1.3後不建議再退回1.2.6 因為會很蛋疼（快取路徑要手動從二層改回一層） its static ranges, they are no longer being used with previous versions either, so this does not actually affect the client's hitrate. ↑1.3版放棄的資料也不會被前版所用所以這不影響H@H客戶端的hitrate Startups past the first one will generally be faster than before, but as it involves a mandatory scan of the cache file structure, it could potentially take longer if you have particularly slow CPU and storage. ↑H@H客戶端第一次之後的程序啟動將會快上許多但因為掃瞄快取資料架構的關係 CPU及硬碟不夠力的話可能鵄嶀W更多時間 Barring any bugs, this release should be far more light-weight than 1.2.6, with reduced CPU usage, 1/4th to 1/2th of the RAM requirements, and a small fraction of the disk I/O for bookkeeping purposes. 更少的CPU用量，少了至少一半的RAM佔用還有小分塊的分頁 After upgrading, you can delete sqlite-jdbc-3.7.2.jar and the hathdl directory from the main directory, as well as hath.db + the log files from the data directory. ↑升級之後，你可以把 sqlite-jdbc-3.7.2.jar 這東西還有hathdl資料夾刪掉順便把hath.db還有log從data資料夾刪掉吧 To update an existing client: shut it down, download Hentai@Home 1.3.0, extract the archive, copy the jar files over the existing ones, then restart the client. ↑要升級H@H客戶端的話，關掉程序，下載1.3版，解壓，複製並覆蓋。然後重啟即可 The full source code for H@H is available and licensed under the GNU General Public License v3, and can be downloaded here. Building it from source only requires the free Java SE 7 JDK. For information on how to join Hentai@Home, check out the Hentai@Home Project FAQ. 乾好累翻到一半就後悔了... 請神囉～ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.216.60.95 ※ 文章網址: https://www.ptt.cc/bbs/AC_In/M.1475382397.A.736.html

→

iammoron

10/02 12:45, , 1^F

10/02 12:45, 1^F

※ 編輯: Fortis931 (61.216.60.95), 10/02/2016 13:14:04

→

fuhu66

10/02 13:23, , 2^F

10/02 13:23, 2^F

→

fuhu66

10/02 13:23, , 3^F

10/02 13:23, 3^F

→

ihateants

10/02 13:26, , 4^F

10/02 13:26, 4^F

→

ihateants

10/02 13:26, , 5^F

10/02 13:26, 5^F

推

a2935373

10/02 13:26, , 6^F

10/02 13:26, 6^F

※ 編輯: Fortis931 (61.216.60.95), 10/02/2016 13:51:19

推

yys310

10/02 14:32, , 7^F

10/02 14:32, 7^F

→

Fortis931

10/02 14:37, , 8^F

10/02 14:37, 8^F

※ 編輯: Fortis931 (220.143.166.42), 10/02/2016 14:43:47

→

gn00465971

10/02 14:58, , 9^F

10/02 14:58, 9^F

→

gn00465971

10/02 14:59, , 10^F

10/02 14:59, 10^F

「自動建立」「掃描」覺得色碼這東西真TM有夠雷哪個天才想出來的...

→

yukitowu

10/02 14:59, , 11^F

10/02 14:59, 11^F

→

yukitowu

10/02 15:00, , 12^F

10/02 15:00, 12^F

要你用downloader吧反正沒client端 proxy也沒什麼用 ※ 編輯: Fortis931 (220.143.166.42), 10/02/2016 15:26:10 ※ 編輯: Fortis931 (220.143.166.42), 10/02/2016 15:33:07

推

BDrip

10/02 15:34, , 13^F

10/02 15:34, 13^F

→

Fortis931

10/02 15:45, , 14^F

10/02 15:45, 14^F

推

jasonger25

10/02 18:11, , 15^F

10/02 18:11, 15^F

→

Fortis931

10/02 20:02, , 16^F

10/02 20:02, 16^F

※ 編輯: Fortis931 (220.143.166.42), 10/02/2016 20:24:52

→

leo870319

10/02 21:06, , 17^F

10/02 21:06, 17^F

→

leo870319

10/02 21:06, , 18^F

10/02 21:06, 18^F

→

leo870319

10/02 21:06, , 19^F

10/02 21:06, 19^F

→

leo870319

10/02 21:07, , 20^F

10/02 21:07, 20^F

推

yys310

10/02 22:11, , 21^F

10/02 22:11, 21^F

→

Fortis931

10/02 22:24, , 22^F

10/02 22:24, 22^F

→

Fortis931

10/02 23:12, , 23^F

10/02 23:12, 23^F

→

Fortis931

10/02 23:12, , 24^F

10/02 23:12, 24^F

→

Kans9527

10/03 01:03, , 25^F

10/03 01:03, 25^F

→

Kans9527

10/03 01:03, , 26^F

10/03 01:03, 26^F

推

Curapikt

10/03 01:06, , 27^F

10/03 01:06, 27^F

→

Curapikt

10/03 01:06, , 28^F

10/03 01:06, 28^F

→ yukitowu: 我只知道某次改版後我就沒拿過排名了... 在那之前我還 12:26: ※ 編輯: Fortis931 (220.143.209.150), 10/03/2016 06:28:40 ※ 編輯: Fortis931 (220.143.209.150), 10/03/2016 06:30:39

→

Fortis931

10/03 06:36, , 29^F

10/03 06:36, 29^F