Hi, I've tested the new nicolive.py and my issue has been resolved. Audio&video are good and no sync issues.

Command used: streamlink -o "outputs/{author}/{title}-{time:%Y-%m-%d-%H-%M-%S}.ts" --ffmpeg-copyts --logfile log-streamlink.txt --loglevel all https://live.nicovideo.jp/watch/lv347277552 best

Version: streamlink 7.1.3+26.g6e8d7ce

Attached logfile if interested. Thankyou!

log-streamlink.txt

I'm using ChatGPT to translate from Japanese to English, so I apologize if the grammar is incorrect.

I have confirmed that all of the following broadcasts can be downloaded successfully.

For the nicolive.py that was submitted as this pull request, there were broadcasts where the video would not play correctly unless --hls-start-offset 6 was specified.
Conversely, for some broadcasts, specifying --hls-start-offset 6 would result in the following error:

[cli][error] Try 1/1: Could not open stream <MuxedHLSStream ['hls-multi', 'https ://assetdelivery.dlive.nicovideo.jp/...m3u8']> (No data returned from stream)

Additionally, I confirmed that all broadcasts, such as official broadcasts that do not require --hls-start-offset 6, could be downloaded normally without specifying --hls-start-offset.

Checked broadcasts:

• https://live.nicovideo.jp/watch/lv347086431
• https://live.nicovideo.jp/watch/lv347108476
• https://live.nicovideo.jp/watch/lv347335723
• https://live.nicovideo.jp/watch/lv346722057

I've tested the new nicolive.py and my issue has been resolved.

👍

According to the log output, the /blank/ segments at the beginning are filtered out correctly and thus don't disturb the actual content output.

But please don't overwrite/replace the plugin file directly. Have a look at the PR feedback link I've posted earlier. You're supposed to install+run the PR branch or sideload the modified plugin file. You're doing neither.

Audio&video are good and no sync issues.

It's a VOD, so there's no sync issue to be expected because both playlists will start at the same time, regardless of access time, unlike live playlists, as explained in the other PR. You also don't need the --ffmpeg-copyts parameter, because it's now forcefully set by the plugin when muxing the audio and video streams.

there were broadcasts where the video would not play correctly unless --hls-start-offset 6 was specified

All of these links are restricted and can't be accessed.

--hls-start-offset is not meant to be used on live streams. It's for VODs, to select a specific range of segments instead of all segments. For live streams where there's a live-edge and only a small window of available segments, this doesn't make sense, which is why you're seeing no data being written to the buffer when setting a nonsensical value.

But without any useful debug logs, none of your claims can be checked.

Btw, this is totally unrelated to this pull request. If there is a plugin issue that can be reliably reproduced, then please open a plugin issue thread and don't comment here.