CCTV Bisa Live, tapi Rekaman Tidak Mau Diputar

Kalau tayangan langsung CCTV lancar tetapi rekaman gagal diputar, kamera dan jaringannya sudah terbukti sehat. Masalahnya ada pada hal yang hanya dipakai saat memutar ulang: rekaman pada jam itu, jam di perekam, format permintaan, jatah sesi pemutaran, dan izin pengguna. Periksa kelimanya sesuai urutan itu.

Urutan ini sengaja dibuat begitu. Dua pemeriksaan pertama paling sering menjadi biang masalah dan paling cepat dicek. Tiga sisanya biasanya menjadi titik macet ketika perekam disambungkan ke software lain, dan tidak terlihat dari layar perekam itu sendiri.

Kenapa tayangan langsung jalan, tetapi rekaman tidak?

Tayangan langsung dan pemutaran ulang lewat jalur yang berbeda. Tayangan langsung ibarat keran yang terus mengalir: penonton memilih kanal, perekam (NVR, kotak penyimpan video dari kamera) meneruskannya. Pemutaran ulang lebih mirip meminta arsip ke petugas gudang. Penonton menyebut rentang waktu, perekam mencarinya di hard disk, membuka sesi tersendiri, memeriksa apakah pengguna ini boleh melihat rekaman lama, baru kemudian mengirim videonya.

Jadi, tayangan langsung yang lancar belum membuktikan apa pun tentang lima kotak di sebelah kanan. Masing-masing pernah gagal di lokasi nyata, dengan gejala yang berbeda.

Apakah rekaman pada jam itu memang ada?

Buka dulu linimasa atau kalender rekaman di perekam itu sendiri sebelum menyalahkan software. Jika jam yang dicari kosong di sana, penonton mana pun tidak akan bisa memutarnya. Penyebab umumnya ada tiga: jadwal hanya merekam saat ada gerakan, disk bermasalah sehingga perekaman berhenti, atau rekaman sudah tertimpa karena masa simpannya lebih pendek dari perkiraan. Soal masa simpan saya bahas di artikel kapasitas penyimpanan CCTV.

Ada juga rekaman yang tersedia tetapi terlihat seperti rusak. Saat uji lapangan di satu lokasi pada September 2026, sebuah perekam diatur menyimpan kira-kira satu gambar setiap delapan detik, sekitar 0,13 gambar per detik, supaya disk-nya awet. Pemutarannya berjalan normal, tetapi hasilnya mirip tayangan slide. Ini urusan pengaturan perekaman. Perbaikannya berupa keputusan soal kapasitas penyimpanan, bukan perbaikan software.

Apakah jam di perekam sudah benar?

Rekaman dicari berdasarkan waktu. Akibatnya, jam yang salah terlihat persis seperti rekaman yang hilang. Di lokasi yang sama, jam perekam lebih cepat 1 jam 27 menit. Perekam itu diatur menyamakan jam ke server waktu di internet lewat NTP, cara perangkat menyetel jamnya sendiri secara otomatis. Masalahnya, jaringan CCTV di sana tidak tersambung ke internet, jadi penyesuaian jam selalu gagal tanpa pemberitahuan.

Akibatnya mudah terlewat. Pukul 10.00 waktu sebenarnya, perekam memberi label 11.27 pada videonya. Operator yang mencari "10.00" justru mendapat kejadian pukul 08.33, lalu melapor bahwa insidennya "tidak terekam".

Zona waktu bisa menambah masalah. Standar ONVIF untuk pencarian rekaman mewajibkan semua waktu, baik di permintaan maupun jawaban, ditulis dalam UTC, waktu acuan dunia yang tertinggal tujuh jam dari WIB, dengan tanda "Z" (ONVIF Recording Search Specification versi 26.06, Juni 2026). Sementara itu, banyak perekam memakai jam lokal tanpa keterangan zona pada antarmukanya sendiri. Software yang mencampur keduanya akan meleset tujuh jam setiap kali mencari rekaman di wilayah WIB.

Dua perbaikan ini sebaiknya berjalan bersama:

• Sediakan sumber waktu yang bisa dijangkau perekam, misalnya server NTP di dalam jaringan CCTV atau router lokasi yang menyediakan layanan itu.
• Di software integrasi, baca jam setiap perekam secara berkala, simpan selisihnya, lalu sesuaikan setiap pencarian dan linimasa. Sistem yang saya bangun membacanya paling sering sepuluh menit sekali. Begitu jam perekam dibetulkan, selisihnya otomatis kembali nol.

Sebelum mengubah jam perekam, catat jam yang tampil, jam sebenarnya, zona waktu, dan pengaturan NTP-nya. Perubahan jam bisa meninggalkan bagian kosong atau tumpang-tindih di linimasa rekaman, seperti diingatkan dalam panduan tanggal dan jam perekam dari Security Wholesalers.

Apakah software meminta rekaman dengan cara yang dipahami perekam?

Di bagian inilah aplikasi pihak ketiga dan sistem analitik video paling sering gagal, padahal aplikasi bawaan perekam bisa memutar rekamannya. Alamat tayangan langsung selalu sama. Alamat pemutaran ulang memuat jam mulai, jam selesai, dan nomor sesi, dan tiap pabrikan punya aturan penulisan sendiri.

Standar ONVIF untuk urusan ini adalah Profile G, yang mencakup perekaman, pencarian, dan pemutaran ulang. Versi terbarunya mewajibkan perangkat memberikan alamat pemutaran lewat GetReplayUri, menerima penanda fitur onvif-replay, dan mengizinkan klien mengatur batas waktu sesi (ONVIF Profile G Specification versi 1.1, Oktober 2025). Perekam yang hanya lulus Profile S atau T mendukung tayangan langsung lewat ONVIF, bukan pemutaran ulang. Perekam di lokasi tadi hanya mencantumkan kompatibilitas ONVIF dasar tanpa Profile G, sehingga pemutaran harus lewat antarmuka khusus pabrikan. Label ONVIF di kotak memang menjanjikan lebih sedikit dari kesan pertamanya; penjelasannya ada di artikel integrasi kamera ONVIF.

Video dikirim lewat RTSP, protokol yang mengatur pembukaan dan kendali aliran video. Pada perekam itu, catatan percakapan RTSP-nya menunjukkan tiga titik masalah:

Jalan keluarnya adalah relay kecil, yaitu perantara di antara pemutar dan perekam yang menulis ulang permintaan-permintaan itu. Relay ini juga mengurus login ke perekam sendiri, sehingga kata sandinya tidak pernah sampai ke pemutar.

Masih ada satu soal lagi, yaitu tempo pengiriman. Protokol pabrikan itu punya header Rate-Control untuk memberi tahu perekam apakah video dikirim secepat waktu aslinya. Kalau dinyalakan, rekaman yang jarang gambarnya tadi datang bergumpal: sekitar 186 KB, lalu sepi enam sampai tujuh detik. Jeda itu cukup lama untuk membuat pemutar mengira sambungannya putus. Kalau dimatikan, klip dua menit terkirim seluruhnya dalam dua detik. Sekarang relay menerima kiriman cepat itu, lalu melepas gambar sesuai cap waktunya. Pemutar pun menerima video dengan tempo yang stabil.

Apakah sesi pemutaran sedang dipakai orang lain?

Jatah pemutaran ulang di perekam jauh lebih sempit daripada jatah tayangan langsung. Spesifikasi model perekam di lokasi itu mencantumkan sepuluh pengguna jarak jauh untuk tayangan langsung, tetapi hanya satu untuk pencarian, termasuk pemutaran ulang. Catatan lapangan menunjukkan satu sesi itu bisa memuat hingga 16 kanal sekaligus. Meski begitu, operator kedua tetap tidak kebagian.

Batas ini juga terasa ketika tidak ada orang lain yang menonton. Sesi yang berakhir tanpa pesan RTSP teardown, tanda dari klien bahwa ia sudah selesai, tetap memegang jatah itu sampai perekam menutupnya sendiri. Pada model itu, waktunya sekitar 60 detik. Selama semenit itu, permintaan berikutnya ditolak dengan galat 560 The user has exceeded the maximum. Bagi operator, kesannya pemutaran ulang rusak.

Software bisa meringankan masalah ini:

• Selalu kirim pesan teardown, termasuk ketika pengguna menutup tab peramban atau berpindah kamera.
• Izinkan permintaan baru dari sistem yang sama mengambil alih jatah dengan rapi, tanpa menunggu batas waktu habis.
• Tampilkan pesan "pemutaran sedang dipakai" beserta nama penggunanya, bukan galat umum.

Tayangan langsung juga punya batasnya sendiri. Perilakunya saat kamera berjumlah ratusan saya bahas di artikel menangani 100+ kamera dengan Go.

Apakah akun ini boleh melihat rekaman?

Banyak sistem memisahkan hak melihat tayangan langsung dan hak melihat rekaman. Di AXIS Camera Station Pro, misalnya, peran Viewer hanya bisa melihat tayangan langsung. Peran Operator bisa diberi akses ke pemutaran ulang dan ekspor. Administrator juga bisa memblokir rekaman yang lebih tua dari umur tertentu (manual pengguna AXIS Camera Station Pro). Pengguna dengan batas umur seperti itu bisa melihat rekaman hari ini, tetapi tidak bisa melihat rekaman minggu lalu. Dari luar, gejalanya tampak seperti pemutaran ulang yang rusak.

Cara mengujinya sederhana: ulangi masalahnya dengan akun operator itu sendiri, bukan akun admin. Kalau lancar di akun admin tetapi gagal di akun operator, jawabannya ada di pengaturan izin. Cara menyusun izin sesuai tugas operator ada di artikel hak akses kamera CCTV.

Gejala mana mengarah ke penyebab mana?

Apa yang perlu diuji sebelum menerima hasil integrasi?

Lakukan pengujian dengan perekam, versi firmware, dan akun operator yang benar-benar dipakai:

1. Putar klip kemarin, lalu klip dari hari tertua yang dijanjikan target masa simpan.
2. Catat satu kejadian nyata menurut jam ponsel, lalu cari di pemutaran ulang pada menit yang sama.
3. Buka pemutaran ulang, tutup tab peramban, lalu segera buka lagi.
4. Jalankan pemutaran ulang dari dua operator pada perekam yang sama secara bersamaan.
5. Ulangi dengan akun operator dan akun viewer.
6. Putar rekaman dari kamera yang hanya merekam saat ada gerakan.

Jika salah satunya gagal, tabel gejala di atas mempersempitnya ke satu penyebab. Perbaikannya biasanya cukup lewat pengaturan atau relay, tanpa membeli perangkat baru. Jika Anda sedang menyambungkan perekam lama ke alur kerja operator atau sistem analitik dan pemutaran ulang menjadi bagian yang paling rewel, saya bisa membantu menelusuri lapisan mana yang bermasalah.