-
-
Notifications
You must be signed in to change notification settings - Fork 80
Release candidate v3.73.0 #789
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| } | ||
| } // namespace | ||
|
|
||
| ClientInfo parseClientInfoFromJson(std::istream& is) |
Check warning
Code scanning / CodeQL
Poorly documented large function Warning
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 18 days ago
To fix the issue, comprehensive documentation should be added to the parseClientInfoFromJson function. The primary remedy is to add a descriptive block comment before the function definition summarizing its purpose, key behaviors, return value, parameters, and possible exceptions. In addition, inline comments should be introduced throughout the function to clarify nontrivial code regions—such as parsing logic, error handling, critical validation steps, and any data mapping that could confuse future maintainers. The changes are all within the file src/libs/subsonic/impl/payloads/ClientInfo.cpp, specifically in and around the definition of parseClientInfoFromJson spanning about lines 190–324. No new imports or library dependencies are needed.
-
Copy modified lines R190-R209 -
Copy modified line R214 -
Copy modified line R220 -
Copy modified line R223 -
Copy modified line R331 -
Copy modified line R335
| @@ -187,17 +187,40 @@ | ||
| } | ||
| } // namespace | ||
|
|
||
| /** | ||
| * Parses a ClientInfo object from a JSON input stream. | ||
| * | ||
| * This function reads the entire input stream, interprets it as a JSON object, | ||
| * and extracts all required and optional ClientInfo attributes. | ||
| * | ||
| * Expected keys include: | ||
| * - name: Name of the client (string, mandatory) | ||
| * - ... (other expected fields, depending on implementation) | ||
| * | ||
| * Throws: | ||
| * - BadParameterGenericError if required fields are missing or malformed, | ||
| * or if parsing fails. | ||
| * | ||
| * Parameters: | ||
| * is: Input stream containing JSON client info | ||
| * | ||
| * Returns: | ||
| * A populated ClientInfo structure. | ||
| */ | ||
| ClientInfo parseClientInfoFromJson(std::istream& is) | ||
| { | ||
| ClientInfo res; | ||
|
|
||
| // Read the entire input stream into a string for parsing | ||
| const std::string msgBody{ std::istreambuf_iterator<char>{ is }, std::istreambuf_iterator<char>{} }; | ||
|
|
||
| try | ||
| { | ||
| Wt::Json::Object root; | ||
| // Parse JSON from string into root object; throws on malformed JSON | ||
| Wt::Json::parse(msgBody, root); | ||
|
|
||
| // Extract mandatory "name" field from JSON | ||
| res.name = parseMandatoryValue<std::string>(root, "name"); | ||
| res.platform = parseMandatoryValue<std::string>(root, "platform"); | ||
| { | ||
| @@ -316,9 +328,11 @@ | ||
| } | ||
| catch (const Wt::WException& error) | ||
| { | ||
| // Wrap and rethrow any JSON parsing or field access exceptions as BadParameterGenericError | ||
| throw BadParameterGenericError{ "ClientInfo", error.what() }; | ||
| } | ||
|
|
||
| // Return the populated ClientInfo object | ||
| return res; | ||
| } | ||
| } // namespace lms::api::subsonic |
|
|
||
| namespace lms::api::subsonic | ||
| { | ||
| TEST(ClientInfo, basic) |
Check warning
Code scanning / CodeQL
Poorly documented large function Warning test
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 18 days ago
To fix the problem, detailed comments should be added to the TEST(ClientInfo, basic) function. The comments should describe the overall purpose of the test, summarize what is being verified, and, for each major step or block of logic, briefly explain what is being checked and why. For example, comment blocks can document the structuring/parsing of the JSON payload, the rationale for the chosen values, and the expectations prior to each significant assertion or logical check. This can be achieved by inserting descriptive comments at the start of the function, above major code blocks, and before any non-trivial assertions. No change to logic or structure should occur; only comments should be added. These edits are to be made directly within src/libs/subsonic/test/ClientInfo.cpp, inside the body of the TEST(ClientInfo, basic) function.
-
Copy modified lines R30-R47
| @@ -27,7 +27,24 @@ | ||
| { | ||
| TEST(ClientInfo, basic) | ||
| { | ||
| // Example as in https://opensubsonic.netlify.app/docs/payloads/clientinfo/ | ||
| /** | ||
| * This test verifies parsing and validation of the ClientInfo structure | ||
| * according to the Subsonic API specification. It uses a comprehensive | ||
| * JSON payload, representative of a real client profile, with multiple | ||
| * nested arrays (direct play profiles, transcoding profiles, codec profiles). | ||
| * Each field and object is checked to ensure correct deserialization and | ||
| * interpretation of values. | ||
| * | ||
| * Key checks include: | ||
| * - Name and platform extraction. | ||
| * - Maximum audio/transcoding bitrates. | ||
| * - Direct play profiles, including container, codec, protocol, and channel handling. | ||
| * - Transcoding profiles validation. | ||
| * - Codec profile parsing and limitations validation. | ||
| */ | ||
|
|
||
| // JSON test data taken from Subsonic payload documentation: | ||
| // https://opensubsonic.netlify.app/docs/payloads/clientinfo/ | ||
| std::istringstream iss{ R"({ | ||
| "name": "Play:1", | ||
| "platform": "Sonos", |
| } | ||
| } // namespace | ||
|
|
||
| TEST(TranscodeDecision, directPlay) |
Check warning
Code scanning / CodeQL
Poorly documented large function Warning test
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 18 days ago
General fix:
Improve documentation for the large test function by adding a comprehensive doc-comment above the TEST(TranscodeDecision, directPlay) function, explaining:
- The purpose and scope of the test ("TranscodeDecision decision logic").
- General structure of the test (large test-case array processed by a generic function).
- How the test cases are grouped or categorized (e.g., direct play, transcoding, failure conditions).
Additionally, insert key inline comments within the testCases array indicating groups of scenarios—so future readers can quickly scan high-level coverage.
Specific steps:
- In
src/libs/subsonic/test/TranscodeDecision.cpp, add a block comment immediately above the line beginning withTEST(TranscodeDecision, directPlay)(line 93). - Optionally, add inline comments within the
testCasesinitializer listing the major types of test case blocks (direct play, transcoding, failure, etc.), but as we only have a section labeled "Direct play" in the shown snippet, we'll at least clarify that. - Do not alter the function’s code, only increase documentation density.
-
Copy modified lines R93-R110 -
Copy modified line R114
| @@ -90,10 +90,28 @@ | ||
| } | ||
| } // namespace | ||
|
|
||
| /** | ||
| * Test suite for TranscodeDecision logic. | ||
| * | ||
| * This test exercises the logic for deciding whether to transcode or allow direct play | ||
| * of audio streams given a wide variety of client profiles, media formats, and codec/container | ||
| * properties. The testCases array captures various scenarios, including: | ||
| * - Direct play (no transcoding required) | ||
| * - Scenarios that trigger audio transcoding for bitrate, codec, or container mismatches | ||
| * - Failure cases where playback is not possible due to unhandled formats or restrictions | ||
| * | ||
| * Each test case specifies a ClientInfo object (playback device capabilities), | ||
| * the source audio properties, and the expected transcode decision (direct play, transcode, or failure). | ||
| * | ||
| * The utility function processTests iterates each scenario, checks that the computed result matches | ||
| * the expected result, and provides index information for easier debugging. | ||
| * | ||
| * This comprehensive parameterized test helps ensure stability as format and device support evolves. | ||
| */ | ||
| TEST(TranscodeDecision, directPlay) | ||
| { | ||
| const TestCase testCases[]{ | ||
| // Direct play | ||
| // === Direct play: scenarios that should allow play without transcoding === | ||
| { | ||
| .clientInfo = { | ||
| .name = "TestClient", |
| valueToCheck = static_cast<unsigned>(source.sampleRate); | ||
| break; | ||
| case Limitation::Type::AudioProfile: | ||
| // TODO; |
Check notice
Code scanning / CodeQL
Commented-out code Note
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 18 days ago
To fix this code style issue, the most effective approach is to either remove the line entirely if no further action is needed, or replace it with a descriptive comment specifying what needs to be implemented. The comment should be clear and actionable (e.g. // TODO: Handle AudioProfile limitation). This removes any ambiguity about commented-out code and maintains code clarity for future developers. Only the comment at line 331 in src/libs/subsonic/impl/endpoints/transcoding/TranscodeDecision.cpp needs to be addressed. No additional imports or scaffolding are required.
-
Copy modified line R331
| @@ -328,7 +328,7 @@ | ||
| valueToCheck = static_cast<unsigned>(source.sampleRate); | ||
| break; | ||
| case Limitation::Type::AudioProfile: | ||
| // TODO; | ||
| // TODO: Handle AudioProfile limitation | ||
| break; | ||
| case Limitation::Type::AudioBitdepth: | ||
| if (source.bitsPerSample) |
No description provided.