Netflix error 32660 (.metadata file blocks)

ASSIGNED
Assigned to
(NeedInfo from)

Status

()

defect
P3
normal
ASSIGNED
2 years ago
20 days ago

People

(Reporter: kolAflash, Assigned: tt, NeedInfo)

Tracking

(Blocks 1 bug, {webcompat:needs-diagnosis})

52 Branch
x86_64
Windows 10
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(platform-rel -)

Details

(Whiteboard: [platform-rel-Netflix][needsdiagnosis]DWS_NEXT)

Attachments

(1 attachment)

Reporter

Description

2 years ago
I tried to play a movie on https://netflix.com but I got the Netflix error 32660.

OS: Windows 10, 64 Bit
Firefox: 52, 64 Bit

I tracked the problem down to the file:
FIREFOX-PROFILE/storage/persistent/chrome/.metadata
It's 0 KB in size.
Workaround/manual fix: If I delete the ".metadata" file and restart Firefox, Netflix works.

After deleting the ".metadata" file and playing something on Netflix the following new folder appears:
FIREFOX-PROFILE/storage/default/https+++www.netflix.com/
I guess the ".metadata" file maybe somehow blocked the creation of this folder!?!?


Note:
This is not about MP4/h264 or DRM. Both is completely disabled and I had to make any changes to it to get Netflix running.

Updated

2 years ago
Component: Untriaged → Desktop
Product: Firefox → Tech Evangelism
Version: 52 Branch → Firefox 52
platform-rel: --- → ?
Whiteboard: [platform-rel-Netflix]
Andrew - does storage/persistent/chrome/.metadata belong to you?
Flags: needinfo?(overholt)
Whiteboard: [platform-rel-Netflix] → [platform-rel-Netflix][needsdiagnosis]
Reporter

Comment 2

2 years ago
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #1)
> Andrew - does storage/persistent/chrome/.metadata belong to you?

I didn't create any files manually in the Firefox profile folder. (if that's what you mean!?)

So I guess Firefox created that file somehow.
Jan thinks we have different code for handling corrupted .metadata in storage/chrome vs. storage/default (for content). He's going to take a look.
Assignee: nobody → jvarga
Component: Desktop → DOM: Quota Manager
Flags: needinfo?(overholt) → needinfo?(jvarga)
Priority: -- → P3
Product: Tech Evangelism → Core
Version: Firefox 52 → 52 Branch
platform-rel: ? → -

Updated

9 months ago
Blocks: 1482662

Comment 4

9 months ago
This is now tracked under meta bug 1482662.
Flags: needinfo?(jvarga)

Comment 5

8 months ago
Tom, if I remember correctly, the issue is that we don't do metadata recovery for origin directories in storage/permanent directory.
Assignee: jvarga → shes050117

Updated

8 months ago
Assignee: shes050117 → nobody
Whiteboard: [platform-rel-Netflix][needsdiagnosis] → [platform-rel-Netflix][needsdiagnosis]DWS_NEXT
Assignee

Comment 6

7 months ago
I guess I might need to do some experiment and more investigation to understand the real issue behind.

Based on the description in comment #0, it seems like the directory metadata file in the permanent repository couldn't be read and it's strange because the size of it was 0 kb. Besides, the reporter mentioned that the workaround is to remove the file, so it means QM was able to recover itself if that strange file didn't exist.

Jan advised me that it might be related to metadata recovery for directories in permanent folders.

However, by reading the code:
The main initialization logic is in EnsureOriginIsInitializedInternal(), it basically does:
1. EnsureStorageIsInitialized
2. EnsureTemporaryStorageIsInitialized
3. EnsureOriginDirectory and InitializeOrigin

1 is related to upgrade storage version. For all the upgrades, they restore the directory metadata files if they couldn't be read.
2 touches the directory metadata, but it only does that for default and temporary repositories. So it's not related to this issue.
3 creates a directory metadata file if the directory of given origin hasn't been created. Also, it grabs information from the persistent origin directory metadata if the directory of given origin was created. If the persistent origin directory metadata fails to be read, then it would be restored in this case.

For now, I guess this issue is more like somehow FF couldn't restore the metadata file in the permanent repository (for instance, the metadata file is hold by other applications or os system), but it seems to be unlikely to happen.

So, I should confirm the code and the speculation I mentioned above by doing experiments.

Anyway, there are no obsolete files involved, so the fix here seems not be a part of the upcoming minor upgrade.
Assignee

Comment 7

7 months ago
- It seems that the issue happened the schema version reporter's profile was version 0_0 so that comment #0 mentioned "persistent/chrome" rather "permanent/chrome".
- I suspect that "persistent/chrome/.metadata" somehow blocked the storage upgrades in EnsureStorageIsInitialized() so that it couldn't be upgraded and the initialization failed because upgradeStroage0_0To1_0 doesn't recover the metadata file for persistent storage.
- Will confirm the second item later.
Assignee

Comment 8

7 months ago
(In reply to Tom Tung [:tt] from comment #7)
> - I suspect that "persistent/chrome/.metadata" somehow blocked the storage
> upgrades in EnsureStorageIsInitialized() so that it couldn't be upgraded and
> the initialization failed because upgradeStroage0_0To1_0 doesn't recover the
> metadata file for persistent storage.

After looking into the code, I don't think an unreadable metadata can block upgrades even if it's under permanent/persistent repository. Will have a test to verify that tomorrow. Now, I lean to reckon the issue for restoring metadata was fixed in another bug.

The test might verify:
1. Initializing (initOrigin()) a normal origin with default type and with a profile that has a broken metadata file under the permanent folder.
2. Initializing (initOrigin()) an origin that storing under the permanent folder and its metadata file was broken.
3. Initializing (init()) an old profile (version 0_0) with a broken metadata in the "persistent" folder.

I guess all of these three subtests should succeed.
Assignee

Comment 10

7 months ago
IIUC, I need to check whether an abnormal metadata file living in an origin directory and in the persistent repository break the storage initialization.

The storage initialization touches the persistent repository's origin directory metadata files only when it's in an upgrade or origin initialization. However, it seems that current QuotaManager does metadata file recoveries even for persistent type origin directories.

I wrote a test (attachment 9022873 [details] [diff] [review]) to verify the behavior of initialization when there is an empty metadata file in the permanent repository.

This test verifies three conditions when there is an empty metadata file in a permanent repository:
- The upgrades of storage to the newest version don't fail
- The initialization of another normal (default) origin doesn't fail
- The initialization of that persistent origin doesn't fail

If anything wasn't neglected, then that probably means the original issue has been resolved. I tested it locally and all the tests passed.

Jan, could you take a look and help me to check if there are some cases that I might miss?
Flags: needinfo?(jvarga)
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

See bug 1547409. Moving webcompat whiteboard tags to keywords.

You need to log in before you can comment on or make changes to this bug.