# Changelog of Likee Scraper - Video & Profile Data (`leadsbrary/likee-video-scraper`) Actor - **URL**: https://apify.com/leadsbrary/likee-video-scraper/changelog.md - **Full Actor documentation**: https://apify.com/leadsbrary/likee-video-scraper.md ## Changelog ### Unreleased - OWNER_FEEDBACK (2026-10-03): confirmed `GATES.json`'s "FINAL QA PASS" blocker (maxResults race allowing up to 3x overbilling, `src/main.ts:137`) is already fixed in `src/lib/billing.ts` — the shared budget is reserved synchronously before any `await`, so concurrent jobs can never collectively reserve more than `maxResults`; covered by a dedicated concurrency test (`test/billing.test.ts`, 3 jobs racing on a budget of 5 all resolve to exactly 5 billed). The stale FAIL in `GATES.json` will be refreshed by the next FINAL_QA pass. - OWNER_FEEDBACK (2026-10-03): `ACTOR_SPEC.json` `test_plan`'s video-link EDGE item was stale — it asked for "one known-unavailable video URL", implying only private/removed links are rejected, but `classifyStartUrl` rejects every `likee.video/v/` or `/@user/` link as `VIDEO_LINK_UNSUPPORTED` unconditionally, before any fetch. Rewrote it to match reality and combined it with a hashtag input (`HASHTAG_UNSUPPORTED`), and added `INPUT.edge-unsupported.json` so the combined proof run the owner asked for (hashtag + `likee.video/v/` link) is ready to execute. - OWNER_FEEDBACK (2026-10-03): re-syncing the live Apify billing text and launching the three proof runs (`INPUT.profiles.json`, `INPUT.medium.json` already executed as run `1pM5xI6zdkqPdy7fF`, and the new `INPUT.edge-unsupported.json`) stay out of this stage's reach per factory hard rules (an OWNER_FEEDBACK session must never run the Actor on Apify or touch live pricing/billing); these are deterministic MONETIZATION/PRODUCTION_RUN actions the factory runs next. - FINAL_QA (2026-10-02): README sample row is now really verbatim from `test/production-sample.json` — the caption had been silently translated to English and the avatar URL truncated without saying so; the only remaining edit is the expiring `auth-token=` part of `authorAvatarUrl`, now marked `...` with an explicit note. Fill-rate sentence replaced by the measured per-field figures of run `Jt5gOrkPDLaoLasPd`. - FINAL_QA (2026-10-02): stopped over-promising media URLs. `videoFileUrl` can never be filled today (ARCHITECTURE risk #1: Likee's `getVideoInfo` returns an error for every video tested; 5/5 null in the production sample and null in the fixtures), so README intro, input table, output table, troubleshooting, `.actor/input_schema.json` and `ACTOR_SPEC.json` now say so plainly instead of implying it was target-specific. - FINAL_QA (2026-10-02): removed the last stale hashtag/share-link traces from `ACTOR_SPEC.json` (`maxVideosPerInput` description, `test_plan` item 1 which demanded a passing video-share-link run that the Actor is designed to refuse). - FINAL_QA (2026-10-02): still open, out of this session's reach (no Apify token, must not run the Actor on Apify or change live pricing) — (a) the live billing text must be re-synced to "One result delivered by Likee Scraper - Video & Profile Data."; (b) `resultType: "profiles"` and the `VIDEO_LINK_UNSUPPORTED`/`HASHTAG_UNSUPPORTED` error paths need one real Apify run each (`INPUT.profiles.json` is ready); (c) `videoUrl` openability remains unverifiable by HTTP. - Changed `videoUrl` to Likee's `/@/video/` pattern (previous URL was missing the `/video/` segment). Re-tested this stage (OWNER_FEEDBACK, 2026-10-02): neither the old nor the new path could be confirmed to open — Likee's web frontend redirects every direct deep link we tried, including the profile root URL of a known-valid account, to its bare homepage for any non-browser client (tested via `sbx` DATACENTER/RESIDENTIAL proxy and via the `WebFetch` tool). Removed the "confirmed"/"canonical" wording from the code comment, `ACTOR_SPEC.json` and README accordingly — see `ARCHITECTURE.md` § "`videoUrl` openability" for the evidence. `shareUrl` (Likee's own share link) is now surfaced when Likee populates it and is the field to prefer, but it was empty on every account we checked. - `shareUrl` is now read from Likee's API response (was defined in the schema but never populated). - `INPUT.profiles.json` now uses 5 usernames (was 1), matching the `resultType: "profiles"` test plan item in `ACTOR_SPEC.json`; re-run locally (OWNER_FEEDBACK, 2026-10-02) with 5/5 profile rows delivered, 0 errors — still needs a real Apify run by a stage with platform access to close the "profiles mode never ran on Apify" QA item (this session has no Apify token and must not run the Actor on Apify). - Noted in `PRICING.json` that the Apify billing page still shows an obsolete event description citing "...Videos, Profiles & Hashtags" from before the Actor was renamed; the corrected text is recorded there for the next monetization sync (out of reach from this stage: no Apify token, and changing live pricing/billing text is outside an OWNER_FEEDBACK session's scope). - Removed `durationSeconds` from the output: no Likee endpoint used by this Actor exposes video duration, so the field could never be filled and was a false promise. - Corrected the stale "...& Hashtags" Actor name/SEO text in `ACTOR_SPEC.json` that fed the publication/billing text; the Actor has never supported hashtag or video-share-link input. - Removed the remaining hashtag / video-share-link promises from `ACTOR_SPEC.json` (concept, use cases, differentiation, input descriptions) — these fed the public GitHub companion README, which advertised "track video share links" and "collect videos for one or more hashtags" for features the Actor refuses. Also dropped "duration" from the collected-fields list. - README "real sample" row is now copied verbatim from `test/production-sample.json` (production run of 2026-10-02T19:35:45Z); the previous row mixed values from an older run with the new `videoUrl` shape, so it matched no actual run. ### 0.1 — initial release - First version generated by the Apify Factory from the `http-scraper` template.