Possible cause for VOD comments crash (ID Hash issue)

[Valeros03]

Hi @GrapheneCt,
First of all, thank you for the amazing work on NetStream!

Regarding the known bug where VOD comments crash the app, I was looking at the source code and I might have found a potential trigger. I can't compile with VDSuite right now to test it myself, so I thought I'd share my findings here:

In CreateCommentListItem(), the button ID is set using param.cell_index directly. For the first comment, the index is 0. I noticed that for Live comments a LIVE_COMMENT_MAGIC offset is used. Without an offset for VOD comments, an ID of 0 might fail to set properly, causing wdg->GetName().GetIDHash() in OnCommentBodyButton() to return a massive wrong hash, leading to an std::out_of_range exception when accessing m_commentItems.at().

Could adding a VOD_COMMENT_MAGIC offset be the solution to this crash, or is there a specific reason it was structured this way?

Thanks again for your time!

[GrapheneCt]

Hello. Thank you for trying to help, but that is not the reason for crashing.

idhash=0 is a valid value, in fact some widgets created internally by PAF will have that exact value as their name idhash (because they are not loaded from an RCO xml and thus do not have a string name which can be hashed to create an idhash). The reason I use LIVE_COMMENT_MAGIC offset is for methods like FindChild() to work correctly, because without offset search will not work correctly for idhash=0, since we may have multiple widgets with that value as described above. It is safe to use idhash=0 directly for VOD comments because methods that require idhash as argument are never used for them.

[Valeros03]

Hi @GrapheneCt,

Thank you so much for the detailed clarification! That makes perfect sense regarding how PAF handles internal widgets and idhash=0. I really appreciate you taking the time to explain the architecture behind it. I will do some further research and debugging in the code to see if I can track down the actual root cause of this specific crash.

By the way, I will be opening a separate issue shortly regarding a completely different (and more critical) bug: the global C1-2784-1 video playback error. I managed to MITM the console traffic and found out it's actually a 400 Precondition Failed error from the InnerTube API caused by the currently hardcoded client payload in the backend. I'll provide all the details and the updated working payloads in the new issue.

Thanks again!