{"action":"closed","issue":{"url":"https://api.github.com/repos/Razzeee/xbmc-test/issues/58","repository_url":"https://api.github.com/repos/Razzeee/xbmc-test","labels_url":"https://api.github.com/repos/Razzeee/xbmc-test/issues/58/labels{/name}","comments_url":"https://api.github.com/repos/Razzeee/xbmc-test/issues/58/comments","events_url":"https://api.github.com/repos/Razzeee/xbmc-test/issues/58/events","html_url":"https://github.com/Razzeee/xbmc-test/issues/58","id":183788335,"number":58,"title":"Support for larger rar'ed .sub subtitles files","user":{"login":"Razzeee","id":5943908,"avatar_url":"https://avatars.githubusercontent.com/u/5943908?v=3","gravatar_id":"","url":"https://api.github.com/users/Razzeee","html_url":"https://github.com/Razzeee","followers_url":"https://api.github.com/users/Razzeee/followers","following_url":"https://api.github.com/users/Razzeee/following{/other_user}","gists_url":"https://api.github.com/users/Razzeee/gists{/gist_id}","starred_url":"https://api.github.com/users/Razzeee/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Razzeee/subscriptions","organizations_url":"https://api.github.com/users/Razzeee/orgs","repos_url":"https://api.github.com/users/Razzeee/repos","events_url":"https://api.github.com/users/Razzeee/events{/privacy}","received_events_url":"https://api.github.com/users/Razzeee/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-10-18T20:03:08Z","updated_at":"2016-10-18T20:03:09Z","closed_at":"2016-10-18T20:03:09Z","body":"**Reported by Gamester17 on 4 Oct 2003 11:25 UTC**\n\r\nSupport for larger rar'ed .sub subtitles files\r\n\r\nSupported for relativly unlimited size rar'ed .sub subtitles\r\n\r\nNot sure how/if it is possible to on-the-fly only \r\nuncompress a section of a file into memory and read it \r\nthen unload it to read in the next section in a rar or zip \r\nfiles. Maybe a dev or someone with more insight intohow \r\nRAR uncompression works can elaborate on that better \r\nthan I\r\n\r\nOtherwise code the application un-rar the whole sub to \r\nharddrive first then only read sections say maybe 256kb, \r\n512kb, 1MB or 2MB of the file at a time into memory \r\nthen unload it if possible (something similar is done with \r\nthe TV-Guide listings.xml). Kawa-X is using harddrive \r\npaging, maybe that could be used if get a better un-rar \r\ncode that first extract direct to harddrive.\r\n\r\nThis is how Mr K, the author of Kawa-X explained it to \r\nme how  Kawa-X is using harddrive <=> memory paging:\r\n\r\n\"The principle is simple. First the data is read from the \r\nrom files, and processed in a suitable form, and it's \r\nwrote back in 256kb chunks on the Z: drive. Why \r\n256kb ? cause it's fast to read or write that amount of \r\ndata, and yet it contains a sufficiently significant \r\namount of data (2048 tiles in the case of NeoGeo)\r\n\r\nThen, in the case of KawaX, 20mb are allocated in RAM, \r\nand divided in 256kb chunks. Each of them will \r\neventually recieve the content of one of the files. Such \r\na chunk is called a page. So, at a given time, we always \r\nhave 80 pages loaded in RAM.\r\n\r\nDuring emulation, the following occurs: Instead of \r\naccessing directly a byte array that would contain the \r\nROM, \r\nI call a function giving it the offset I need, and that will \r\nreturn a pointer to the relevant data\r\nThe function checks if the needed page is loaded. \r\nYes ? good, we return a derivated pointer. \r\nNo ? We load the needed page from Z: to the least \r\nrecently used page in central RAM.\r\n\r\nLeast recently is decided this way: when one page is \r\naccessed, its flag is set to 0, and at the end of each \r\nframe, all pages are incremented. \r\nSo at a given time, the page with the highest flag is the \r\none that was used the longest ago, and will be ditched \r\nfirst when needed.\" \r\n\n\nMigrated-From: http://trac.kodi.tv/ticket/58"}}
{"actor":{"display_login":"Razzeee"}}