Mga update

Sinasabi ng HolyArrs kung may bagong bersyon, pero hindi nito iyon ini-install. Ikaw ang magpu-pull ng bagong image kapag ayos sa iyo.

Alamin kung may bagong bersyon

1. Buksan ang Status page (http://your-server:6262/health).
2. Basahin ang Updates. Dapat makita mo ang isa sa mga ito:

Mensahe	Kahulugan
“HolyArrs 1.2.0 is out, newer than this one.”	Mag-update kapag handa ka na
“This is the newest version.”	Walang gagawin
“No HolyArrs release is published yet.”	Walang laman ang feed. Walang mali
“The last check did not work: …”	Hindi naabot ang feed, madalas walang internet
“The update check is off: …”	Naka-off sa Settings

3. Para magtanong agad, piliin ang Check now (suriin ngayon) o Check again (suriin ulit). Kailangan nito ng permiso na Change settings (baguhin ang settings).

Lumalabas din bilang babala sa kalusugan ang mas bagong bersyon. Sa ilalim lang ng Updates lumalabas ang nabigong pagsusuri.

Mag-update

1. I-pull ang bagong image at i-restart: docker compose pull, tapos docker compose up -d.
2. Magsisimula ang HolyArrs. Kung binabago ng bagong bersyon ang pagkakaimbak ng data, gagawa muna ito ng backup, saka i-a-update ang data. Dapat makita mong bumukas ang app sa bagong bersyon.

Tip

Ang nabigong hakbang ng update ay binabawi, at titigil ang HolyArrs sa isang page na nagsasabi kung ano ang nangyari. Mananatiling backup ang data mo mula bago ang update.

Bumalik sa naunang bersyon

Hindi kayang baguhin ng HolyArrs ang sarili nitong image, kaya patatakbuhin mo ang naunang image at ibabalik ng HolyArrs ang naunang data.

Caution

Anumang nabago pagkatapos ng update, gaya ng mga bagong pamagat, settings at kasaysayan, ay wala sa backup bago ang update.

1. Palitan ang tag ng image sa compose file mo (o sa docker run) ng naunang tag, halimbawa holyarrs/holyarrs:<older version>.
2. Patakbuhin ang docker compose up -d.
3. Kung hindi binago ng update ang data, magsisimula ang naunang bersyon. Tapos na.
4. Kung hindi, isang page ang ipapakita ng naunang bersyon sa halip na ang app. Piliin ang Put back the data from before the update (ibalik ang data mula bago ang update).
5. I-type ang isang-gamit na code. Hanapin ito gamit ang docker logs <container>; hanapin ang “one-time code”.
6. Susuriin ng HolyArrs ang backup, ilalagay ito sa lugar at titigil. Dapat makita mong magsimula ulit ang container sa data na iyon sa pamamagitan ng restart policy nito. Kung wala nito, simulan mo ito mismo.

Kung walang page: docker exec <container> /holyarrs restore --pre-update, tapos docker restart <container>. Kung walang Docker: ihinto ang HolyArrs, patakbuhin ang holyarrs restore --pre-update, simulan ito.

Walang binubura. Lilipat ang mas bagong data sa backups/before-restore-<time>/, kaya puwede mo itong i-undo. Kapag higit sa isang bersyon ang binalikan, pipiliin ang pinakabagong backup bago ang update na mababasa ng bersyong iyon.

Mga pagpipilian

Lahat ay nasa Settings > Health checks. Ang huling tatlo ay nasa advanced na bahagi ng card.

Setting	Default	Baguhin kapag
Check for a newer HolyArrs	On	Ayaw mo ng anumang request palabas
Check for updates every	araw	Gusto mo ng mas kaunting pagsusuri: 3, 7, 14 o 30 araw
Release feed	Walang laman (mga bersyon ng HolyArrs)	May sarili kang feed
Feed may be on the local network	Off	Nasa sarili mong network ang feed mo
Include test versions (like 1.2.0-rc1)	Off	Gusto mo ng abiso para sa mga test na bersyon

Kung hindi gumana

Sintomas: “The last check did not work.” Dahilan: walang internet ang server, o nasa lokal na network ang sarili mong feed. Solusyon: suriin ang internet access, o i-on ang Feed may be on the local network.

Sintomas: hindi ma-save ang release feed. Dahilan: may pangalan, password, ?query o #fragment ang address, o hindi ito nagsisimula sa http:// o https://. Solusyon: alisin ang mga bahaging iyon.

Sintomas: huminto ang update dahil kulang ang disk space. Dahilan: walang lugar para sa kopya at sa update. Solusyon: magbakante ng espasyo kung nasaan ang config folder, saka magsimula ulit.

Sintomas: tinatanggihan ng page sa pagbalik ang code mo. Dahilan: lumang code, o 10 maling code mula noong huling simula. Solusyon: kopyahin ang code mula sa pinakabagong linya ng log. Pagkatapos ng 10 maling subok, i-restart ang container at gamitin ang bagong code.

Mga tampok na hindi pa bukas

May mga tampok na naka-off bilang default sa bersyong ito. I-on ang mga ito sa sarili mong panganib. Habang hindi pa bukas, nakatago ang mga page at menu item nila, “not found” ang sagot ng mga API route nila at hindi tumatakbo ang mga gawain nila. Nananatili ang data na na-save mo para sa kanila.

Para mag-on ng isa, idagdag ang switch nito sa HOLYARRS_FLAGS, pinaghihiwalay ng kuwit, at i-restart ang container:

environment:
  HOLYARRS_FLAGS: "subtitle_sites,alert_channels_more"

Alisin ang pangalan at i-restart para i-off. Babalik ang mga nakatagong setting kapag in-on mo ulit.

Switch	Tampok
row_title_stats	Mga estadistika ng pamagat sa mga row ng Explore, sa Appearance
trakt_lists	Trakt key, mga listahan ng Trakt at mga review ng Trakt. Nananatiling bukas ang mga listahan ng TMDB
alert_channels_more	Mga alerto sa Telegram, ntfy, Gotify, Pushover at webhook. Nananatiling bukas ang Discord at email
subtitle_sites	Mga site ng subtitle at paghahanap ng subtitle. Nananatiling bukas ang wika mo sa subtitle
emby_signin	Mag-sign in gamit ang Emby. Gumagana pa rin ang pag-refresh ng Aklatan ng Emby
go_back	Ang panel na Go back sa Status page. Gumagana nang wala ito ang mga hakbang sa Bumalik

Walang nagbago pagkatapos magdagdag ng switch? Suriin ang baybay (lowercase, underscore) at i-restart ang container, hindi lang ang page.

Para sa mga eksperto

Ano ang ipinapadala ng pagsusuri

Isang request sa api.github.com para sa pinakabagong bersyon, na may User-Agent: HolyArrs/<version> lang. Walang account, key o listahan ng media. Kapag naka-off ang pagsusuri, walang request.

Sine-save ang huling sagot, kaya hindi susuri ang restart bago ang takdang oras. Hanggang 15 s lang ang hinihintay ng isang pagsusuri, hanggang 512 KB lang ang binabasa at hanggang 3 redirect lang ang sinusundan, at hindi kailanman lumilipat sa pagitan ng http at https. Lalabas lang ang link ng release notes kapag tumuturo ito sa mga release page ng HolyArrs sa GitHub; kung hindi, plain text ang bersyon.

Tumatanggap ang Release feed ng sagot na estilong GitHub, listahan ng mga release, anumang JSON na may version, o plain text na may bersyon. Laging tinatanggihan ang mga address ng cloud metadata. Itinuturing na mas luma ang test na bersyon kaysa sa karaniwang bersyon.

Ang backup bago ang update

Bago baguhin ang naka-imbak na data, ginagawa ng HolyArrs ang mga ito:

1. Sinusuri kung may lugar para sa kopya at sa update. Kung wala, walang magbabago. Laktawan gamit ang HOLYARRS_SKIP_SPACE_CHECK=yes.
2. Kinokopya ang bawat database sa backups, sinusuri ang kopya at nagsusulat ng sha256 file sa tabi nito. Pagkatapos ng 3 nabigong kopya, walang magbabago.
3. Pinapatakbo ang bawat hakbang ng update nang hiwalay at sinusuri ito. Binabawi ang nabigong hakbang; nananatili ang mga natapos na. Simulan ulit ang parehong bersyon para ituloy mula sa nabigong hakbang gamit ang parehong kopya.

Pagkatapos ng unang maayos na simula, nagiging holyarrs-backup-pre-update-<time>.zip ang kopya, na may paglalarawang gaya ng “before updating from 1.1.0 to 1.2.0”. Lumalabas ito sa Settings > Backups at sa holyarrs restore --list. Pinananatili ang pinakabagong 3; hindi ito kailanman inaalis ng iskedyul ng backup. Walang ginagawang backup ang bagong install o ang update na hindi nagbabago ng data.

I-verify ang image

Simula sa 1.0.3, bawat image sa Docker Hub ay pinipirmahan ng release run sa GitHub. Walang key na idi-download. Suriin ang isang image gamit ang cosign. Ilagay ang bersyong pinapatakbo mo, gaya ng 1.0.3, kung saan nakasulat ang <version>:

cosign verify holyarrs/holyarrs:<version> \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp '^https://github.com/HolyArrs/HolyArrs/\.github/workflows/sign\.yml@refs/(tags/[0-9.]+|heads/main)$'

Dapat makita mo ang The cosign claims were validated. Anumang iba pa ay nangangahulugang hindi galing ang image sa release run ng HolyArrs: huwag itong patakbuhin.

May dala ring tala ang image kung paano ito ginawa at listahan ng laman nito (isang SBOM). Suriin ang mga ito gamit ang GitHub CLI:

gh attestation verify oci://docker.io/holyarrs/holyarrs:<version> --repo HolyArrs/HolyArrs

Nasa bawat GitHub release ang parehong mga file: .sigstore.json (pirma), .intoto.jsonl (tala ng build) at .sbom.spdx.json (laman).

Kaugnay

• Mga backup
• Mga pagsusuri ng kalusugan
• Mga bahagi at safe mode