[Bug] Bilibili analysis hangs at "Updating format table" when formats only have `filesize_approx`

## 📝 Description

YTSage 5.5.0 hangs indefinitely at **"Updating format table"** when analyzing the following Bilibili video:

https://www.bilibili.com/video/BV1fBM86MEMa/

The video metadata itself is successfully extracted by yt-dlp. However, all returned DASH formats have:

```text
filesize = null
filesize_approx = <valid numeric value>
```

This appears to expose two related issues in YTSage's format table handling:

1. Video formats are filtered out when `filesize` is `None`, even if `filesize_approx` is available.
2. Audio formats with `filesize=None` are allowed into the format table, but the table code later appears to perform arithmetic directly on `filesize`, which would result in a `NoneType` error.

This happens **before any actual download starts**.

## 🔗 Affected Video URL

https://www.bilibili.com/video/BV1fBM86MEMa/

Video title:

```text
【睡前消息1075】最先被非洲移民炸掉的国家 可能是南非
```

## 🔄 Steps to Reproduce

1. Start YTSage 5.5.0 on Windows.

2. Paste:

   ```text
   https://www.bilibili.com/video/BV1fBM86MEMa/
   ```

3. Click **Analyze**.

4. Wait for metadata extraction.

5. YTSage reaches **"Updating format table"**.

6. The format table never finishes updating and the UI remains stuck at that stage.

The underlying formats can be inspected independently with yt-dlp:

```powershell
yt-dlp --dump-single-json --no-warnings "https://www.bilibili.com/video/BV1fBM86MEMa/" > bv.json

$j = Get-Content .\bv.json -Raw | ConvertFrom-Json

$j.formats |
    Select-Object format_id,vcodec,acodec,filesize,filesize_approx,resolution |
    Format-Table -Auto
```

Relevant output:

```text
format_id vcodec                         acodec    filesize filesize_approx resolution
--------- ------                         ------    -------- --------------- ----------
30216     none                           mp4a.40.2                  7191906 audio only
30232     none                           mp4a.40.2                  7191906 audio only
30280     none                           mp4a.40.2                  7191906 audio only
30016     avc1.64001E                    none                      16192260 640x360
30011     hvc1.1.6.L120.90               none                      13261275 640x360
100022    av01.0.08M.08.0.110.01.01.01.0 none                      10405809 640x360
30032     avc1.64001F                    none                      24142921 852x480
30033     hvc1.1.6.L120.90               none                      18979224 852x480
100023    av01.0.08M.08.0.110.01.01.01.0 none                      14622288 852x480
30064     avc1.640028                    none                      40227138 1280x720
30066     hvc1.1.6.L120.90               none                      31637795 1280x720
100024    av01.0.08M.08.0.110.01.01.01.0 none                      24257091 1280x720
30080     avc1.640032                    none                      80004615 1920x1080
30077     hvc1.1.6.L150.90               none                      60997210 1920x1080
100026    av01.0.08M.08.0.110.01.01.01.0 none                      45598791 1920x1080
```

In other words, for every returned format:

```text
filesize        = null
filesize_approx = valid
```

## ✅ Expected Behavior

YTSage should accept valid formats even when yt-dlp only provides `filesize_approx`.

The format table should display the available Bilibili streams, including:

* 360p AVC / HEVC / AV1
* 480p AVC / HEVC / AV1
* 720p AVC / HEVC / AV1
* 1080p AVC / HEVC / AV1
* available audio-only streams

If an exact filesize is unavailable, YTSage could display the approximate size or `N/A`.

For example, a reasonable fallback would be:

```python
size = f.get("filesize")

if size is None:
    size = f.get("filesize_approx")

if isinstance(size, (int, float)):
    filesize = f"{size / 1024 / 1024:.2f} MB"
else:
    filesize = "N/A"
```

## ❌ Actual Behavior

YTSage reaches:

```text
Updating format table
```

and remains there indefinitely.

No selectable video/audio formats appear and downloading cannot be started.

The yt-dlp extraction itself succeeds and returns all expected DASH formats.

## 🖥️ Environment

* YTSage Version: 5.5.0
* yt-dlp Version: 2026.08.19
* OS: Windows
* Python Version: N/A (pre-built YTSage EXE)
* Deno Version: 2.9.5
* FFmpeg Version: N-126342-gf88b741dbf-20260831
* Installation Method: pre-built Windows EXE

## 📸 Screenshots/Logs

[ytsage.log](https://github.com/user-attachments/files/31727346/ytsage.log)

<img width="902" height="780" alt="Image" src="https://github.com/user-attachments/assets/8e7e7883-15da-4a3b-bcfa-d53953ccd0e0" />

## 🛠️ Possible Fix

The issue appears to be in the format-table handling of nullable `filesize` values.

### 1. Do not require exact `filesize` for video formats

In `ytsage/gui/ytsage_gui_format_table.py`, video formats appear to be filtered using logic equivalent to:

```python
video_formats = [
    f
    for f in self.all_formats
    if f.get("vcodec") != "none"
    and f.get("filesize") is not None
]
```

For the affected Bilibili video, this filters out **all video formats**, because yt-dlp supplies only `filesize_approx`.

A format should probably not be considered invalid merely because its exact filesize is unknown.

For example:

```python
video_formats = [
    f
    for f in self.all_formats
    if f.get("vcodec") != "none"
]
```

### 2. Fall back to `filesize_approx` when rendering the Size column

Audio-only formats are intentionally allowed without an exact filesize, but the table rendering code appears to use logic equivalent to:

```python
filesize = f"{f.get('filesize', 0) / 1024 / 1024:.2f} MB"
```

If the dictionary contains:

```python
"filesize": None
```

then:

```python
f.get("filesize", 0)
```

returns `None`, not `0`.

That means the expression effectively becomes:

```python
None / 1024 / 1024
```

which would raise:

```text
TypeError: unsupported operand type(s) for /: 'NoneType' and 'int'
```

A safer implementation would be:

```python
size = f.get("filesize")

if size is None:
    size = f.get("filesize_approx")

if isinstance(size, (int, float)):
    filesize = f"{size / 1024 / 1024:.2f} MB"
else:
    filesize = "N/A"
```

This would also make the format table work with extractors where yt-dlp can only estimate stream size.

## 📌 Additional Context

This looks specifically related to the distinction between yt-dlp's:

```text
filesize
```

and:

```text
filesize_approx
```

The affected video is not missing formats: yt-dlp successfully returns 12 video streams and 3 audio streams.

Therefore this does not appear to be a Bilibili extraction failure, authentication issue, FFmpeg problem, or download failure. The problem occurs while YTSage is processing the already-extracted format metadata for display.

The YTSage README currently recommends updating yt-dlp/nightly when the format table does not appear, but in this case yt-dlp is already successfully returning the formats; the failure happens afterward in the GUI format-table stage.

It may be worth making the format table generally tolerant of nullable metadata, using:

```text
filesize -> filesize_approx -> N/A
```

rather than assuming `filesize` is always numeric.

---

### Checklist

* [x] I have searched existing issues to avoid duplicates
* [x] I have provided the affected video URL
* [x] I have included clear steps to reproduce
* [x] I have attached relevant screenshots/logs
* [x] I have provided the available environment details


Navigation Menu

Uh oh!

[Bug] Bilibili analysis hangs at "Updating format table" when formats only have `filesize_approx` #151

📝 Description

🔗 Affected Video URL

🔄 Steps to Reproduce

✅ Expected Behavior

❌ Actual Behavior

🖥️ Environment

📸 Screenshots/Logs

🛠️ Possible Fix

1. Do not require exact `filesize` for video formats

2. Fall back to `filesize_approx` when rendering the Size column

📌 Additional Context

Checklist

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Uh oh!

[Bug] Bilibili analysis hangs at "Updating format table" when formats only have filesize_approx #151

Description

📝 Description

🔗 Affected Video URL

🔄 Steps to Reproduce

✅ Expected Behavior

❌ Actual Behavior

🖥️ Environment

📸 Screenshots/Logs

🛠️ Possible Fix

1. Do not require exact filesize for video formats

2. Fall back to filesize_approx when rendering the Size column

📌 Additional Context

Checklist

Activity

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

[Bug] Bilibili analysis hangs at "Updating format table" when formats only have `filesize_approx` #151

1. Do not require exact `filesize` for video formats

2. Fall back to `filesize_approx` when rendering the Size column