Brickfrog @ brickfrog @lemmy.dbzer0.com

Posts

0

Comments

308

Joined

2 yr. ago

Feeding it into DBinfo I can see the appended playlist files (appended with .1, .2, .3 and so on) call the same numbered stream files with no appended .1, .2, .3

Yeah that's probably right since each disc likely had the same named files in them (e.g. same name .m2ts files).

Where I am getting stuck in this logic is why there are 12 index files in the upload while there should only be 6 disks as listed in the .XML files.

You're right, that makes no sense either :/

Personally I would consider this corrupted data & just move on / try to find another source for that content. Otherwise seems like you're going to be spending a fair amount of time trying to reverse engineer whatever happened here.

What is your final goal? Are you just trying to mux the .m2ts stream files into .mkv containers? I suspect you can work with the .m2ts files directly & feed that right into ffmpeg or makemkv for the same results (granted not sure if you'll lose anything extra like subtitles). The trick is figuring out which .m2ts is which episode or whatever, you already have enough clues to figure out which .m2ts files are being referenced.

Also fun fact: Most media players can play .m2ts directly without needing to mux into a .mkv container first. I usually just hardlink the actual .m2ts files & rename them as needed for Kodi or whatever e.g. "blahblah.s01e01.m2ts"

I downloaded a BDMV folder that should be a copy of a six disk box set.

The download only has one BDMV folder? You should have 6 different BDMV folders if it's supposed to be six discs. Sort of sounds like the uploader tinkered with the data & maybe flattened the whole thing into one massive disc?

Once I organized this into a streams/playlist/clip/meta folders by file type and feed it into makemkv I can only see disk one.

Yeah that makes sense, 1 BDMV folder = 1 disc.

I'm not actually sure how you'd even go about flattening 6 discs into one BDMV folder, thing is many of those files (especially the .m2ts files) have the same duplicate name across multiple discs. Maybe the uploader used Blu-ray editing software to do that, or maybe you only have 1 disc not 6.

My hunch is maybe the uploader purposely re-wrote the whole thing into one massive disc so you're not really looking at 6 discs anymore. Not sure if this'll help but maybe try feeding the whole thing into BDInfo & see what it comes up with, at the very least it'll be able to give you some visibility into which specific .m2ts streams each .mpls is linked to, & that way you can hopefully decipher the different episodes/whatever that you're looking for.

PS - If this data was edited by the uploader I'm not sure how easy or feasible it would be to figure out how to split it back into 6 discs. (assuming this data is indeed 6 discs)

You forgot the most important part, subscribe to a usenet provider. Your usenet download client can't download anything without a provider.

Just a FYI all Lemmy instances have an /instances page where you can see instances it is linked to as well as blocked instances. For this one it is at https://lemmy.dbzer0.com/instances

This instance does block instances for spam and suspicious/spammy behavior (dbzer0 admin also maintains https://fediseer.com).

Nice, I was just wondering when that feature would be rolled out. It'll definitely cut down on people talking about blocking instances they don't like.

Agreed, I don't care that much about that instance - but also mainly browse Subscribed posts in Lemmy so usually just view communities I'm interested & subscribed into. Other people should probably just do that, vs browsing All, if they're seeing too much in their feed they don't like.

The real issue is that the Lemmy web ui & most apps/frontends don't support instance blocking as a user setting. Eventually when/if that's an option available to most Lemmy users this will become a non-issue.

When starting out here I ended up with a few accounts on different Lemmy/Kbin instances, interestingly the dbzero instance usually has the best overall performance/uptime from what I've seen. So no complaints here :)

For what it's worth I'm usually on here via Tor & haven't had issues on dbzero, a lot of other Lemmy instances trip up over Tor connections and end up with crappy performance with Cloudflare/captchas/etc. or just block it outright.

If the VPN does not support port forwarding is it still possible to use for Linux torrents?

Yes with caveats. Torrent swarms need at least 1 connectable (port forwarded) peer for the swarm to exchange data. If all the peers are firewalled (not port forwarded) then all the swarm peers can see each other but cannot exchange torrent data so there will be no uploading/downloading in that swarm.

Generally speaking you won't notice much difference in large torrent swarms since those swarms usually have some/many connectable peers. But in smaller torrent swarms you may have trouble since your odds are worse that you'll find connectable peers in those swarms.

PS - Yes you are still seeding/uploading while firewalled (not port forwarded) just not very effectively. While firewalled your best connections will be with connectable peers in the torrent swarms. Not much to think about with public torrents but it'll kill your ratio at private trackers for sure.

Yes, usually at the end of the year if there are funds to spare I'll donate to a bunch of FOSS projects, other non-profits, websites, etc. especially if I use them year-round.

From the /c/piracy rules

2. Don’t request invites, trade, sell, or self-promote

You may want to update your post to mention which version of qBittorrent 4.6.0 you're on.

e.g. are you using the build with Libtorrent 1.2.x or Libtorrent 2.0.x?

Libtorrent 2.0.x does tend to use more memory during runtime (especially when you have many actively uploading/downloading torrents) but it's fine overall, the OS / kernel knows to redistribute memory away from qBittorrent to other applications as needed. In other words if nothing is crashing then you should be okay.

That said I've mainly tinkered with Libtorrent 2.0.x clients on Windows (Deluge & qBittorrent) so there might be something I'm missing specific to Linux or Docker. qBittorrent with "Physical memory (RAM) usage limit" set to its max will basically let Libtorrent use as much memory as it likes.. it is lower priority memory so in theory as long as everything else in Windows is working the other applications can still request memory & run properly. Funny enough with Deluge I don't think it even has a RAM usage limit setting so Deluge with Libtorrent 2.0.x will happily use the max memory available to it.

Same here.

Interestingly back when myself & others were moderating subs on Reddit, & we locked the subs during the protests, the majority of PMs us mods would receive were from randoms that found a link via Google or wherever & were trying to view the post. It did make me wonder how often people browse Reddit just because they stumbled into a link via Google or whatever search engine.

I can't see how Reddit would survive without the big search engines, without those random visitors the ad revenue would plummet.

See the /c/Piracy community rules

2. Don’t request invites, trade, sell, or self-promote

FYI the community rules

2. Don’t request invites, trade, sell, or self-promote

To be fair the site claims they have an open source application yet there is no link to the source code.

Another commenter mentioned github so I searched around & found a potential github project but they're at 4.0.0 release while this site you linked claims to offer a "4.2.0.apk" so I guess it's some random 4.2.0 release version?

Are you able to link the source code that this website refers to?

EDIT: Nevermind I think I found it, the .apk being offered matches this project at github https://github.com/recloudstream/cloudstream/releases though I'm not too sure if the .ws site being linked here is associated with the github project (the github page doesn't mention the .ws site and the .ws site doesn't mention the github page)

Something like this would seem to make more sense to run over I2P I'd think. But it looks like the devs aren't interested in trying to go that route

https://github.com/onionshare/onionshare/issues/377

Maybe in the future someone will fork the project to work over I2P eventually.

What kind of hellhole is that city? I had an impression it was extremely expensive but also very wealthy. The more I hear the worse it seems.

LOL start reading about Dubai sometime.

Same here.

Hoping they'll offer a better discount + trade in deal later on, maybe Black Friday? Otherwise I may end up skipping the Pixel 8.

TBH my Pixel 7 still works great so it's not a big deal sticking with it but now that I cracked the exterior a nice trade in discount could convince me to upgrade :D

The Vuze devs forked the code and went on to create and continue developing BiglyBT. So technically if you want to keep using that client best to switch over to BiglyBT.

You can stay with the old Vuze if you want but it's no longer developed since it lost its devs.

https://en.wikipedia.org/wiki/Vuze#Development_hiatus

https://torrentfreak.com/former-vuze-developers-launch-biglybt-a-new-open-source-torrent-client-170803/

You can try !mediashare@lemmy.world

Or install Jellyfin and host your own media yourself.