# Dataset viewer stuck in "disabled" state, need help > Source: > Published: 2026-08-28 21:16:03+00:00 Uh… I think the NFAA tag may be the suspicious part here: The strongest clue I can find is that this does **not** look like a normal Parquet/config-generation failure or a repository-level `disabled` state. It looks much more like the Dataset Viewer rejecting the repository at its **support/eligibility check**, specifically because of the `not-for-all-audiences` tag. Your `disabled: false` observation is still useful, but it appears to answer a different question: ``` php Hub repository disabled? -> false Dataset Viewer eligible/allowed? -> separate decision ``` The current [ dataset-viewer support-check code](https://github.com/huggingface/dataset-viewer/blob/main/libs/libcommon/src/libcommon/operations.py) has a dedicated branch for `not-for-all-audiences` is one of the recognized NFAA tags in `TAG_NFAA_SYNONYMS` ``` NotSupportedTagNFAAError Not supported: dataset viewer is disabled. ``` That second line is exactly the message in your report. More importantly, I did a point-in-time check against the **live public datasets-server endpoints**, rather than relying only on the GitHub source. For `RicemanT/booru-essence-2026` , both `/is-valid` and `/splits` returned HTTP **501** with: ``` X-Error-Code: NotSupportedTagNFAAError ``` and: ``` {"error":"Not supported: dataset viewer is disabled."} ``` So for this particular repository, the NFAA path is not just a guess from the source code: the production service itself is currently classifying it that way. I therefore would **not spend more time on random README edits, whitespace commits, or Parquet re-uploads yet**. Those were reasonable attempts, but if this support check is what is firing, they are happening downstream of the real decision. The first useful branch is simpler: `not-for-all-audiences` is accidental or no longer appropriateThere is one complication worth mentioning: I do **not** think it is safe to generalize this into “all public NFAA datasets can never have a Viewer.” I can currently find public NFAA datasets such as [ QianyueWang/openGov](https://huggingface.co/datasets/QianyueWang/openGov?not-for-all-audiences=true), `p1atdev/open2ch` `larryvrh/PIPPA-TavernFormat` `200` with `viewer: true` ; their datasets-server revision headers also matched their current Hub revisions, so this does not appear to be merely a stale search-result artifact.That makes the target-specific diagnosis fairly strong, while leaving the **production-wide semantics** for HF to clarify. So I think you have already supplied most of what a maintainer would need. I would stop perturbing the repository for now and focus the support question on this distinction: The live datasets-server response for this repo is `NotSupportedTagNFAAError` , which matches the current public-NFAA support check. Is that the intended production behavior for this dataset? If so, is there currently a supported Viewer/preview path for appropriately labeled public NFAA datasets? If not, should this repository be reprocessed or have its Viewer state corrected? The [ dataset-viewer repository](https://github.com/huggingface/dataset-viewer) recommends reporting dataset-page Viewer errors in the dataset’s own discussion, so this thread already seems like the right place to resolve the part that cannot be determined from public state. At least from what is observable publicly, I would put **NFAA eligibility first, ordinary cache/backfill second**.