What do your settings look like?
Did you have any Imports other than what's in D:\Imports?
What settings? The ones for my Personal Media under Sources? They don't have the "new" named D:\imports\Tv or \Movies or \Videos paths added to them at all. I DO have other personal media on network drives that are mapped there, but none of them are in a folder called "Imports", like they are on the former RP drive.
Should they be added there? I never added them when this drive was on the Raspberry Pi, it just magically found them, or however it did, I never paid attention to that at all.
IF I try to map them, I get this:
General > Basic Setup
General > Library Database
Sources > Personal Media
All looks normal.
So none of the duplicates you see are also in \\TP-Share or \\wdtvlive ?
Correct.
It's very odd why it duplicated the listing of these imported files when I restored the database from moving Channels from the RP to the new Beelink mini. It's a LOT of files also, so hard to deal with.
Well, if nobody else has anymore input on a easier way to possibly fix the duplicates Channels created on Restore than the above, guess I'll just have try it and see what happens. Hopefully it won't blow up something else.
Ok, it's in process. Renaming then 'Prune' went quickly, the Scan Personal Media will likely take many hours to re-import, and regenerate all it does.
Ok, it finally finished at 2:22pm. It worked, and eliminated all the duplicate file references!
P.S. This is a new Beelink Mini S computer that I just bought on Amazon, with 8gb Ram, and 256gb SSD. $129 on sale. After seeing how much ram Windows 11 sucks down (almost 60%), I HIGHLY recommend that people that switch to one of these and intend on staying on Windows, spends the extra $25 and gets the 16gb ram, 500gb SSD version. You just can't upgrade later for as cheap as that.
@maddox Ok, maybe there's yet still another issue. After it was all done, I ran the Troubleshooting tool. It successfully green-lighted everything as expected. I then took a look at the Log File, and saw this in the log:
2025/01/24 14:42:39 [Recovery] 2025/01/24 - 14:42:39 panic recovered:
runtime error: invalid memory address or nil pointer dereference
runtime/panic.go:262 (0x666ab7)
runtime/signal_windows.go:401 (0x666a87)
github.com/fancybits/channels-server/http_dvr_file.go:479 (0x2052f68)
github.com/gin-gonic/[email protected]/context.go:185 (0x1ff7cc1)
github.com/fancybits/channels-server/http_dvr_file.go:35 (0x1ff7c09)
github.com/gin-gonic/[email protected]/context.go:185 (0x1fe0f61)
github.com/fancybits/channels-server/http.go:412 (0x1fe0c79)
github.com/gin-gonic/[email protected]/context.go:185 (0x1fe0be6)
github.com/fancybits/channels-server/http.go:389 (0x1fe0bd4)
github.com/gin-gonic/[email protected]/context.go:185 (0x1fe0b17)
github.com/fancybits/channels-server/http.go:364 (0x1fe0847)
github.com/gin-gonic/[email protected]/context.go:185 (0x1fe044e)
github.com/fancybits/channels-server/http.go:326 (0x1fdfabf)
github.com/gin-gonic/[email protected]/context.go:185 (0xec50ce)
github.com/gin-gonic/[email protected]/recovery.go:109 (0xec50bb)
github.com/gin-gonic/[email protected]/context.go:185 (0xec4204)
github.com/gin-gonic/[email protected]/logger.go:249 (0xec41eb)
github.com/gin-gonic/[email protected]/context.go:185 (0xeb74ca)
github.com/gin-contrib/[email protected]/sessions.go:54 (0x1fe36e4)
github.com/gin-gonic/[email protected]/context.go:185 (0xeb74ca)
github.com/gin-contrib/[email protected]/gzip.go:47 (0x1fe399c)
github.com/gin-gonic/[email protected]/context.go:185 (0x207b4a2)
github.com/fancybits/channels-server/http.go:588 (0x207b490)
github.com/gin-gonic/[email protected]/context.go:185 (0xec3631)
github.com/gin-gonic/[email protected]/gin.go:633 (0xec30a0)
github.com/gin-gonic/[email protected]/gin.go:589 (0xec2bd1)
net/http/server.go:3210 (0x9b278d)
net/http/server.go:2092 (0x991b8f)
runtime/asm_amd64.s:1700 (0x690000)2025/01/24 14:42:42 [Recovery] 2025/01/24 - 14:42:42 panic recovered:
runtime error: invalid memory address or nil pointer dereference
runtime/panic.go:262 (0x666ab7)
runtime/signal_windows.go:401 (0x666a87)
github.com/fancybits/channels-server/http_dvr_file.go:479 (0x2052f68)
github.com/gin-gonic/[email protected]/context.go:185 (0x1ff7cc1)
github.com/fancybits/channels-server/http_dvr_file.go:35 (0x1ff7c09)
github.com/gin-gonic/[email protected]/context.go:185 (0x1fe0f61)
github.com/fancybits/channels-server/http.go:412 (0x1fe0c79)
github.com/gin-gonic/[email protected]/context.go:185 (0x1fe0be6)
github.com/fancybits/channels-server/http.go:389 (0x1fe0bd4)
github.com/gin-gonic/[email protected]/context.go:185 (0x1fe0b17)
github.com/fancybits/channels-server/http.go:364 (0x1fe0847)
github.com/gin-gonic/[email protected]/context.go:185 (0x1fe044e)
github.com/fancybits/channels-server/http.go:326 (0x1fdfabf)
github.com/gin-gonic/[email protected]/context.go:185 (0xec50ce)
github.com/gin-gonic/[email protected]/recovery.go:109 (0xec50bb)
github.com/gin-gonic/[email protected]/context.go:185 (0xec4204)
github.com/gin-gonic/[email protected]/logger.go:249 (0xec41eb)
github.com/gin-gonic/[email protected]/context.go:185 (0xeb74ca)
github.com/gin-contrib/[email protected]/sessions.go:54 (0x1fe36e4)
github.com/gin-gonic/[email protected]/context.go:185 (0xeb74ca)
github.com/gin-contrib/[email protected]/gzip.go:47 (0x1fe399c)
github.com/gin-gonic/[email protected]/context.go:185 (0x207b4a2)
github.com/fancybits/channels-server/http.go:588 (0x207b490)
github.com/gin-gonic/[email protected]/context.go:185 (0xec3631)
github.com/gin-gonic/[email protected]/gin.go:633 (0xec30a0)
github.com/gin-gonic/[email protected]/gin.go:589 (0xec2bd1)
net/http/server.go:3210 (0x9b278d)
net/http/server.go:2092 (0x991b8f)
runtime/asm_amd64.s:1700 (0x690000)
If you need it: 399acc6b-f6fd-474c-86d8-6348a7695fad
It all SEEMS to be working ok though, as far as I can tell anyway.
Would be really awesome if we could use the hash of the file and the tail section of the file path (e.g. the filename) and recognize duplicates from that... I still have the issue where I see dupes for a while because my workflow is to record on the ChannelsDVR, and then move the files to my Windows Server file shares on a batch job... they're identical files, other than (some small prefix) of the file path... so comparing the name and the file hash would understand them.
It would be possible, of course, to only compute the hash once per appearance of the file if it was stored in the ChannelsDVR database... so then the workflow is: Channels downloads to local drive, computes hash when completed, then does all the metadata fun. Later, the background job moves the file to the server, where the Personal Media is setup, and thus the file is seen again. We compute the hash, see that it matches a file with the same base name (in a specific level of directory hierarchy if we really wanted to be flexible), and knows that this was a relocation. For sanity, it could check the original (local) path and see that the file has disappeared, and then just update the path in the CDVR database and skip all the other work (don't even need a new File ID).
Doing this would ALSO enable me to do some housekeeping on the recordings once on the NAS. I would MUCH rather have each TV Show Season in its own folder, each Movie in a Genre folder, for example.
Recognizing the simple file move prevents the loss of all the metadata, play history, etc. and preserves the Verified flag and all the file-specific info CDVR is tracking.
Wouldn't work in my case, because the path and such was exactly the same on the duplicates. The ONLY thing that was different, was the File Id number. IF you deleted one file, it deleted both of them, as it was only a single file, in a single location. Channels just somehow made two records of it. Beats me how it did that during migration, but it did.
I'd been meaning to move from the RP dedicated image, to a mini pc anyway. This just forced me to finally do so.
Indeed, it wouldn't work after things were messed up... but if it was in place before, the second File ID would never have been allocated. You wouldn't have had duplicates to resolve 
1 Like