Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

setRecordingDirectory replies "acknowledged" while silently disabling recording on a bad path

Đang mở
  • Có gì không ổn?
#3,937 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 5 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
cpp
Lĩnh vực
api, audio-video-rtc

Hướng nghiên cứu

Bắt đầu với SetRecordingDir trong src/recorder/jamcontroller.cpp và handler setRecordingDirectory trong src/serverrpc.cpp; so sánh nhánh lỗi của chúng với GetRecorderErrMsg() trong src/serverdlg.cpp và getRecorderStatus. Tái hiện một đường dẫn không hợp lệ và một phiên ghi đang diễn ra, sau đó xác định phản hồi lỗi RPC dự kiến và hành vi trạng thái của recorder trước khi xác định phạm vi bao phủ cho cả hai trường hợp.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

🤖 AI: jamulusserver/setRecordingDirectory always replies "acknowledged", but a bad path silently disables recording and discards the stored directory — with nothing to roll back to, and if a recording was already running, it ends the WAV mid-session while the jam continues, unannounced.

Root cause, confirmed on current main (4a43f6f6). SetRecordingDir tears down the existing recorder thread (EndRecorderThread() + wait()) before validating the new directory; on failure strRecordingDir is wiped to "". The RPC handler reports "acknowledged" regardless of which branch ran.

Measured on a headless build (wt-3861, 2026-08-12; the cited lines read identical on current main). A parent-is-a-file path and a path beyond PATH_MAX both flip enabled/initialised True → False and recordingDirectory → "", RPC still "acknowledged".

A recording already in flight stops at the instant the bad call returns. A growing WAV (950,272 → 975,916 bytes across a good call) sits flat at every checkpoint afterward, while getClients keeps reporting the same live connection throughout — the jam itself is untouched, so nobody in the room is told recording just ended.

The identical failure is loud in the GUI — GetRecorderErrMsg() drives a QMessageBox::warning — and silent over RPC, which discards the same string. getRecorderStatus's errorMessage does carry it, and the method's own doc comment says to re-check — a caller who does so can catch this — but nothing prompts the re-check, and "acknowledged" does not suggest a session recording just silently ended.

🤖 This message was written by AI and reviewed by @mcfnord.

Ngôn ngữ chính
C
Star
1.1k
Fork
248
Merge trung bình
7 ngày 14 giờ
Pull request đã merge (30 ngày)
6

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của jamulussoftware/jamulus

Tất cả issue của jamulussoftware/jamulus

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.