Greetings. Before last update, if an asset is not selected, Podlove indicated that in the “Validate Podcast Files” list with a line in the Dashboard. However, since last update, Podlove indicated that asset is missing, even when I explicitly did not select it. See image:
Just wanted to confirm that I have the same issue with my Podlove instance. As described in the Sendegate Community already, episodes published before mid November 2023 where fine, episodes after that have this issue.
If you check in the problematic episodes, you see that a greyed out filename is there and three “???”. However, checking the older episodes, they only state “File not found” for the disabled assets. Enabling and disabling an asset in a newer episode doesn’t fix this, neither does clicking the “Verify” button.
After lots of digging through the source code, I’ve found the problem: the way assets are stored has changed. Previously, only after an asset had been found, an entry into the database was made. But now, for each asset type of any new episode, an empty entry is made into the database.
The dashboard does the following: check if an asset has an ID. If there is no ID, then the “-” is shown. If it does have an ID, check if the size is greater than 0. If it is, all’s well. If it isn’t, show the red X.
That’s under the assumption that an asset with its ID is only created if an asset has been identified/found/verified. However, since this has changed, the search for episode assets returns a bunch of IDs that have 0 file size because the aren’t found.
One solution is a check for whether an asset is active or not. Then the dashboard correctly shows the “-” again for all assets that are disabled and a red “X” for assets that are enabled but have infact a size of 0.
In my instance, I hacked the files and it’s working as expected.
Thanks for investigating! This is quite a problem for me, as I use different assets/feeds to separate a public and a (secret) patreon feed. I just made a post about this here: Issue with Episodes Assets - Episode appears in disabled Feed!
I’m not sure if there is a fix for this @ericteubert ?
I added some more screenshots here: Assets werden "gesucht", obwohl sie deaktiviert sind - #3 von Simon - Podlove Publisher - Sendegate
What’s in your template for the feeds? That’s probably where the problem is now.
I created an issue for it Bug: Dashboard "inactive" indicator · Issue #1472 · podlove/podlove-publisher · GitHub
Not sure the issues are related.
/edit: alright, after some investigation, maybe it is 
Thanks for checking it out! <3 I’ll wait for an update.
Yesterday, I was too busy which is why I couldn’t supply the information about the fix. This morning, I put some time aside for it … and it’s fixed already #tooFastForMe 
Thanks!
Thank you so much! I just installed the Update, and it looks good now. Wohoo! <3 <3 <3
@ericteubert When I added my shownotes pdf, I noticed that my Template didn’t pick up the asset although it was marked as active and found alright. A quick look into the database showed me that I had multiple entries for the asset type attached to the episode ID. Some of them where marked as active (1) and some of them as inactive (1). The entry with the smallest ID has inactive. After deleting the extra entries out of the database, the Template worked just fine again.
Investigating futher showed that when you turn an asset inactive, the entry in the DB gets updated. However, when you mark it active again, a new entriy is created in the DB.
The Dashboard is uneffected by this as it is picking up the active-ness of the latest asset. However, the Template makro to check for the active state of an asset is broken now. Also, the DB is filled up with incorrect references to assets.
Oh no 
Enabling an asset uses “find or create” logic, but I adjusted the “find” part in the latest update to only look for active entries. Thank you for reporting and investigating!
Issue created: Investigate: Duplicate entries in MediaFile table · Issue #1475 · podlove/podlove-publisher · GitHub
Bugfix release is on the way. That only prevents further duplicates, but I need to write a migration or some other solution to clean up the database. (Fix duplicate MediaFile entries · Issue #1476 · podlove/podlove-publisher · GitHub)
Hey Eric,
I noticed a tiny little potential bug - maybe related to the issue from before:
Since the last update, my newly created episode points now to the m4a/mp4 files when i access it via episode.files[1].publicUrl("download")
My complete code this download area is:
<div class="download-area"><div style="display:table-row">
<div class="download-button"><a href="{{ episode.files[0].publicUrl("download") }}">Download (<b>MP4</b>)</a></div>
<div class="download-button"><a href="{{ episode.files[1].publicUrl("download") }}">Download (<b>MP3</b>)</a></div>
<div class="download-button"><a href="https://www.youtube.com/channel/UC2u-LDzNz2NRQh4exRmYcmA/videos?sort=dd&shelf_id=0&view=0">Auf <b>Youtube</b> anschauen</a></div>
</div></div>
For the older episodes, it still works very well:
Both episodes use the same setup when it comes to the asset (left is episode 78 which works still well, right is episode 80 which now links to m4a):
I would not recommend relying on the order of files, and am surprised it worked reliably so far It’s better to give your asset template identifiers and refer to them in templates.
episode.file("mp3").publicUrl("download"), episode.file("m4a").publicUrl("download") etc.
Thank you very much for the tip! It works perfectly fine! <3