Restrict telemetry markers to error/critical paths only

[Copilot]

In production, the Ethan logger only emits ETHAN_LOG_MILESTONE and ETHAN_LOG_FATAL entries. Since mLOGLEVEL_INFO, mLOGLEVEL_WARN, and mLOGLEVEL_MIL were all mapped to ETHAN_LOG_MILESTONE, every routine success event (e.g. "Found source for video", "Create pipeline", "Gstreamer subs enabled") was generating a telemetry marker in production.

Changes

• playerLogManager/PlayerLogManager.cpp — Remapped MW log levels to Ethan log levels so only mLOGLEVEL_ERROR produces a telemetry-visible entry:

// Before: INFO, WARN, and MIL all collapsed to ETHAN_LOG_MILESTONE (telemetry)
case mLOGLEVEL_INFO:
case mLOGLEVEL_WARN:
case mLOGLEVEL_MIL:
default:
    ethanLogLevel = ETHAN_LOG_MILESTONE;  // emitted in production
    break;

// After: each level mapped individually; only ERROR reaches a telemetry tier
case mLOGLEVEL_INFO:    ethanLogLevel = ETHAN_LOG_INFO;     break;  // filtered
case mLOGLEVEL_WARN:    ethanLogLevel = ETHAN_LOG_WARNING;  break;  // filtered
case mLOGLEVEL_MIL:     ethanLogLevel = ETHAN_LOG_WARNING;  break;  // filtered
case mLOGLEVEL_ERROR:   ethanLogLevel = ETHAN_LOG_FATAL;    break;  // telemetry

ETHAN_LOG_INFO and ETHAN_LOG_WARNING are below the production filter threshold, so they are suppressed at runtime without requiring any changes to individual MW_LOG_MIL / MW_LOG_WARN call sites.

Original prompt

Update the middleware-player-interface code so that telemetry markers are only provided for critical issues and errors. Remove or bypass all telemetry markers currently triggered by normal (successful) events. Ensure only error-handling or critical failure paths emit telemetry markers, while routine success cases do not generate telemetry.

• Locate all instances in the codebase where telemetry markers (or similar logging/instrumentation) are emitted.
• Refactor logic so that only error and critical issue code paths trigger telemetry.
• Ensure all normal, successful code paths do not emit telemetry markers.
• Test or check code paths to confirm intended behavior.
• Do not change any unrelated functionality.

Target branch: feature/RDKEMW-16028.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: https://github.com/rdkcentral/middleware-player-interface/tree/feature/RDKEMW-16028
Provide telemetry markers only for critical issues and errors and dont need normal events that we got in success case

Assistant: To address your request, you should update the repository so that telemetry markers are only emitted for critical issues and errors—normal or successful events should not trigger telemetry.

Action plan:

1. Locate the Telemetry Integration:
   Identify where telemetry markers (or calls to telemetry functions/logs) are made in the codebase.

2. Update Event Handling:
   Adjust the logic so that only events corresponding to critical issues or errors result in a telemetry marker; normal/success cases should bypass this.

3. Test change:
   Ensure that telemetry for success paths is suppressed, and only error/critical telemetry is sent under failure scenarios.

Would you like me to open a pull request in rdkcentral/middleware-player-interface (branch: feature/RDKEMW-16028) to make this change?
If yes, please provide any specifics (e.g., the telemetry marker function name, or if you want marker messages/contents to change as well), or I’ll proceed with a general implementation based on standard practices.

User: yes

Assistant: I will open a pull request in rdkcentral/middleware-player-interface (branch: feature/RDKEMW-16028) to ensure telemetry markers are only provided for critical issues and errors and not for normal/success events. You’ll be notified once the PR is ready for your review.

This pull request was created from Copilot chat.