Geschiedenisbestand naar DB

BUG / NIEUWE FUNCTIE

Versie 2.5.7 64-bit

Windows 10 x64

Het zou fijn zijn als er een optie was om de geschiedenisinformatie in een sqlite-db of iets dergelijks op te slaan. Mijn geschiedenisbestand wordt behoorlijk groot, en na ongeveer een half jaar stopt MCEBuddy ermee bestanden tijdens het scannen te herkennen; ik moet ze handmatig toevoegen of, sinds kort, laat ik een powershell-script ze via de CLI toevoegen.

Zodra ik het geschiedenisbestand leeg, is de scan binnen enkele seconden klaar en, als ik sommige ad-hoc-mappen niet heb verwijderd, voegt hij ze alsnog aan de conversietaken toe. Ik vermoed dat het aan het aantal records in het geschiedenisbestand ligt.

Als er een optie is om in een database op te slaan, verwacht ik dat de zoekopdracht sneller verloopt en dat, bij corruptie of het opnieuw aanmaken, eerdere records eventueel uit een backup terug te zetten zijn.

Gewoon regelmatig de geschiedenis wissen. Is er een reden waarom je moet weten of MCEBuddy een bestand heeft verwerkt in plaats van iets anders? Als het bestand een duplicaat is (dus al aanwezig), zal MCEBuddy het bestand niet verwerken. Het niet in de geschiedenis staan maakt niet uit.

Of mis ik iets?

De geschiedenis wordt binnen een monitoringlocatie gebruikt om een reeds geconverteerd bestand niet opnieuw te verwerken, tenzij de optie “Opgenomen video’s opnieuw monitoren” is ingeschakeld.

Er zijn momenten waarop ik een bestand opnieuw moet verwerken, dus vink ik deze optie aan. Als jij in dezelfde situatie zit @Nick_Skoy, dan kun je proberen deze optie aan te vinken om te zien of het de nieuwe bestanden oppikt. Het lijkt erop dat het de geschiedenis-analyse zou omzeilen.

Sorry voor de late reactie. Ik was dit weekend uit de stad en gisteren druk bezig.

Ik heb een HDHomeRun Prime en gebruik NextPVR. Niet al te ver van wat ik begrijp. Ik heb een aantal shows ingesteld om “ALLE afleveringen” op te nemen en andere om “Alleen nieuwe afleveringen”. Dus ik denk dat het probleem zit bij shows in de categorie “ALLE afleveringen”. Ik neem even “Friends” als voorbeeld. Het wordt op meerdere zenders uitgezonden en het maakt me niet uit of een aflevering meerdere keren wordt opgenomen. Of zoals ik begrijp zal het alleen dezelfde aflevering opnemen als deze op een andere zender wordt uitgezonden.

Ik heb gezien dat wanneer ik de afleveringen opnieuw toevoeg aan MCEBuddy via de command line of ze sleep en neerzet, het de gegevens oppikt, herkent dat het bestand eerder is geconverteerd op basis van de geschiedenis, vervolgens het bestand verwijdert en doorgaat naar het volgende item in de wachtrij. Dus het doet ook het opruimen. Wanneer mijn geschiedenisbestand groot of corrupt is geworden (hoewel ik het bestand nog steeds prima kan lezen en geen zichtbare corruptie zie), vindt de zoekopdracht de opgenomen shows niet en blijft MCEBuddy inactief. Die bestanden stapelen zich dan op en er zijn momenten geweest waarop er 100+ shows/films zijn die geconverteerd moeten worden, maar dat gebeurt niet. Ik voeg de bestanden toe aan MCEBuddy via de command line of handmatig via slepen en neerzetten en na verloop van tijd voegt het ze toe aan de wachtrij, verwerkt ze – ofwel converteert ze of detecteert dat het al geconverteerd is – en verwijdert het bronbestand uit de opnamefolder.

Ik hoop dat dit een beetje logisch is/helpt…

Het klinkt alsof er twee soorten „dubbele/geschiedenisverwijdering” kunnen plaatsvinden.

  1. Het bestand staat in de history-database/log (dus dezelfde naam van de opname-DVR) en wordt daarom overgeslagen voordat er verder wordt verwerkt.
  2. Het bestand wordt initieel verwerkt totdat de bestemmingsnaam is bepaald; als dat bestand er al ligt, wordt het overgeslagen voordat (of misschien na) de verdere verwerking plaatsvindt – ik weet die detail niet zeker, maar ik hoop dat MCEBuddy kan besluiten het over te slaan voordat het de moeite neemt het bestand te verwerken.

Scenario #1 hangt af van de invoernaam: als die identiek is aan een eerdere opname volgens de history-regels, wordt hij genegeerd.

Scenario #2 hangt af van de uitvoernaam: als die volgens de bestemmingsregels al bestaat, wordt hij als dubbel beschouwd.

Bijvoorbeeld: mijn HDHR staat op „alles opnemen” (de hele serie; het is (nog?) niet zo slim als mijn TiVo om de „nieuw”-vlag in de gids te gebruiken). De tuner zet daarom begintijd HHMM en eindtijd HHMM in de bestandsnaam, plus het kanaal. Elke uitzending levert dus een apart bestand op, ongeacht of de gids episode-informatie of andere metadata bevat.

Bijna alle shows op PBS-subkanalen (CreateTV, ik kijk naar jou) hebben geen episode-informatie of show-ID’s; ze belanden altijd als eenmalige items in mijn „Specials”-map in plaats van in een serie-met-seizoenen-en-afleveringen. Of het nu verschillende episodes zijn of simpelweg herhalingen van dezelfde aflevering op een ander tijdstip.

Voor mijn „Specials”-profielen moet ik daarom de starttijd in de uitvoernaam opnemen, zodat ik kan zien dat er mogelijk meerdere of dubbele episodes zijn. Zouden ze allemaal uitkomen op „Showname-SE-RecordDate”, dan blokkeert de eerste de rest en worden de anderen als dubbel verwijderd onder scenario #2.

Voor TV-series wil ik dat juist níét: ik wil een „de eerste opname wint”-beleid. Daarom bevat mijn uitvoernaam voor series (die een episodenummer in de metadata hebben) alleen de „FirstAirDate”, niet de „RecordDate”.

Sportuitzendingen zijn doorgaans live en alleen relevant voor de datum van het evenement, dus hun hernoemingsregel gebruikt „RecordDate”, niet „FirstAirDate”, omdat sommige gidsdata de „FirstAirDate” op de startdatum van het hele sportprogramma zetten – bijvoorbeeld Monday Night Football (niet dat dat accuraat is, maar ik gebruik het als herkenbaar voorbeeld). In een wedstrijdreeks staat het wedstrijdnummer niet altijd als „episode” in de metadata; Game 3 van de „World Series 2022”-show kan bijvoorbeeld als titel „World Series 2022 Game 3” verschijnen (waardoor de hele serie opnemen een puinhoop wordt in de DVR) of als Episode 3 binnen de serie. Door altijd de „RecordDate” in de bestandsnaam op te nemen, los ik dat probleem op, ongeacht wat de gids of metadata zegt.

Hopelijk helpt dit om te begrijpen wat MCEBuddy in jouw geval doet. Je kunt ook de forums doorzoeken op mijn posts met mijn bestandshernoemingsregels die elk type show (TV, Film, Sport en „Overig”) naar aparte locaties sturen en verschillende uitvoernamen gebruiken die goed samenwerken met mijn Plex-opstelling.

De probleemshows zijn de PBS-programma’s die in mijn Specials-map belanden; die moet ik handmatig ontdubbelen en verplaatsen naar de juiste serie, met het juiste seizoen en aflevering. Meestal laat ik de opnametijd als suffix staan en bewaar ik de beste versie die MCEBuddy heeft verwerkt.

Kun je me je geschiedenisbestand toesturen via een PB (of laat me weten hoeveel regels/items het bevat)? We hebben het getest met tot 100.000 items zonder problemen. We hebben de INI-database-engine ook grondig herzien in de nieuwste 2.5.8-bètaversie om nog grotere databases toe te staan.